Cream of the Crop 3

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 3 / Cream of the Crop 3.iso / utility / dea201.zip / DEA.DOC < prev next >

Wrap

Text File | 1993-12-01 | 183KB | 3,671 lines

█████████████ █████████████████ ███████ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ██ ██ ██ ██ ███ ██ ██ ██ ██ ███ ██ ███████████ █████████████████████ ███ ██ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ █████████████ █████████████████ ██ ██ The Data Encryption Algorithm Release v.2.00 ___________________________________________ An Advanced Cryptographic Software Tool For Confidential & Private Computer Information In the 1990's And Beyond Documentation and User's Reference Manual ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Copyright (c) 1993 by Nellis du Maurier Information Security All Rights Reserved Published and printed in Canada, November 1st, 1993 Version Release Dates ____________________________________________________ Initial DEA v.2.00 (ß) release: August 30, 1993 Final Release Date: November 1st, 1993 Release v.2.01: December 1st, 1993 (current version) Distribution: Worldwide ---------------------------------------------------- ************************************** * _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- * * * * Washington, having been asked by * * an officer on the morning of a * * battle, what were his plans for * * the day, replied in a whisper, * * Can you keep a secret? On being * * answered in the affirmative, the * * general added --so can I. * * * * _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- * ************************************** LICENSE AGREEMENT Nellis du Maurier Information Security hereby grants non-registered users a limited license of thirty (30) days. Trial evaluation period shall become effective from the date of acquisition of The Software. During this time licensee may determine the suitability and applicability of this software to their needs. Licensee may use, copy, and distribute The Software subject to the following conditions and restrictions: (i) The Software and its documentation may not be modified in any manner whatsoever, except that it may be archived into a single file for ease of distribution or uploading to bulletin board systems. (ii) The Software may not be disassembled, reassembled, reverse engineered, or de-compiled. (iii) No fee or price may be charged for The Software or accompanying documentation beyond a reasonable amount to cover the cost of distribution of The Software. (iv) The Software and its documentation may not be translated into any other language without the prior written approval of the publisher. (v) The documentation file DEA.DOC must accompany the executable file DEA.EXE. (vi) The Software is not distributed in conjunction with any other product. (vii) Licensee is not authorized to rent, lease, or sublicense The Software. (viii) Licensee is not entitled to any source code. (ix) Licensee may not create derivative works of The Software or incorporate any part thereof into another computer program or product. DISTRIBUTION The DEA Software package is a Shareware product because it is distributed through public information channels so that prospective buyers can have the opportunity to evaluate the product before making the final purchase decision. if you decide to continue using The Software beyond the thirty (30) day trial evaluation period, then you are under both legal and moral obligations to register this software product with Nellis du Maurier Information Security; the Data Encryption Algorithm (DEA Release v.2.00) Software IS NOT FREE. THE SHAREWARE DEFINITION It is important to understand that 'Shareware' is not a type of software. It is a method of distributing software to prospective buyers. In essence, a shareware product extends a measure of good faith to the potential purchaser in that he / she is given the opportunity to evaluate the software before buying it. This is analogous to taking a car for a test drive before you buy it. Since the operating overhead is low, the shareware prices are low also. Shareware offers the best money-back guarantee: if you don't use the product, you don't pay for it. There are good and bad programs in both the Shareware and commercial domain; Shareware is not to be thought of as second-hand software. While some may think that Shareware is second grade software, for, if it was really good quality, it would be called 'commercial'. The best reply to this type of attitude is to remember that Shareware is also a commercial enterprise. There is, not surprisingly, far more software variety and affordability to be found in Shareware. There are many truly useful software products only marketed via Shareware channels. By supporting the shareware software provisions, you assure yourself the continued existence and support of software you have chosen to use on a routine and daily basis. This honesty also carries forward to future programmers from who's products you may also benefit. The DEA is user-supported software. COPYRIGHTS The Data Encryption Algorithm (DEA) version 2.00 programs and documentation are copyright 1993AD and are the licensed property of the publisher: Nellis du Maurier Information Security All commercial rights and rights of translation into foreign languages are reserved by the publisher. Unauthorized duplication is strictly prohibited. PATENTS The Data Encryption Algorithm, DEA Release v.2.00 incorporates cryptographic technology never before used in cryptographic designs. These new designs cover the DEA key data structure, the production of one-time-pads, and the DEA v.2.00 Cipher Function. Patents are pending for these unique designs. DISCLAIMER OF LIABILITY Licensee must accept and acknowledge the fact that the Data Encryption Algorithm (DEA v.2.00) is in the process of peer evaluation. Unlike other computer software, competent computer information security algorithms must undergo a period of rigorous testing, inspection, and analysis by trained experts. The availability of The Software is designed to encourage competent peer evaluation of this lengthy process, and will ultimately benefit you, the end user, in making an intelligent choice. Nellis du Maurier Information Security has no control over the conditions under which licensee operates and uses The Software and therefore cannot warrant the performance and results so obtained from the use of these products. Nellis du Maurier Information Security shall not be responsible for problems caused by hardware failure, or operating system difficulties when using The Software. Nellis du Maurier Information Security shall not in any case be liable for incidental, consequential, indirect, or other damages resulting from use of The Software. Nellis du Maurier Information Security shall not in any case be held legally responsible for any costs incurred by the use of The Software resulting in lost profits, lost revenues, lost data, costs of re-creating lost data, costs of substitute software, or to persons other than licensee for other costs, including, but not limited to legal and law enforcement. Nellis du Maurier Information Security shall not in any case be held legally responsible for obstruction of justice. In situations where the Data Encryption Algorithm obstructs federal law enforcement efforts, the licensee is under full legal obligation to disclose the DEA key data to allow the recovery of the indicated plain text document(s). By using The Data Encryption Algorithm Software, licensee agrees to hold harmless Nellis du Maurier Information Security from all legal costs involved and / or incurred in the process of litigation and / or prosecution. WARRANTY Nellis du Maurier Information Security warrants The Software to operate in accordance with the accompanying documentation and to be free of defects. This warranty shall also cover the shipping media when The Software is ordered directly from Nellis du Maurier Information Security. Data integrity of The Software cannot be guaranteed when The Software has been obtained from any other source. Further, great care has been exercised with respect to both The Software and the Security Analysis. The DEA v.2.00 was designed, written, and published November 1st, 1993 by: Nellis du Maurier Information Security 33 Isabella St., Ste. 1005 Toronto, Ontario M4Y 2P7 Canada Version Release History v.2.00 November 1st, 1993 v.2.01 December 1st, 1993 Current version: 2.01 █████████████ █████████████████ ███████ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ██ ██ ██ ██ ███ ██ ██ ██ ██ ███ ██ ███████████ █████████████████████ ███ ██ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ ███ ███ ██ ██ ██ █████████████ █████████████████ ██ ██ Release v.2.00 TABLE OF CONTENTS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Chapter One ═══════════════════ 1.1 PURPOSE OF THE DATA ENCRYPTION ALGORITHM 1.2 SUMMARY OF FEATURES OF THE DATA ENCRYPTION ALGORITHM 1.3 SYSTEM REQUIREMENTS 1.4 THE DATA ENCRYPTION ALGORITHM - QUICK TECHNICAL OVERVIEW 1.5 WHY USE THE DEA AS AN ENCRYPTION TOOL TO PRESERVE PRIVACY? 1.6 THE PURPOSE AND USE OF CRYPTOGRAPHY 1.7 VARIETIES OF CONFIDENTIAL INFORMATION Chapter Two ═══════════════════ 2.1 GETTING STARTED WITH THE DATA ENCRYPTION ALGORITHM 2.2 INSTALL.BAT AND SETTING THE DOS PATH * 2.3 RUNNING THE DEA FOR THE FIRST TIME 2.4 LEARNING TO USE THE DEA VIA AUTOMATED BATCH FILES * 2.5 THE DEA COMMAND LINE SWITCHES Chapter Three ═══════════════════ * 3.1 DEA DEFAULT FILE NAMING CONVENTIONS 3.2 DOS FILE TYPES & FILE ATTRIBUTES 3.3 THE DEA.KEY FILE LOCATION ERROR 3.4 ADVANCED METHOD OF LOCATING THE DEA.KEY FILE VIA THE DOS REDIRECTION PIPE 3.5 MAKING THE DEA.KEY FILE READONLY 3.6 THE DEA EMBEDDED FILE PATH 3.7 DEA AUTOMATIC PROCESSING FILE CLEAN-UP 3.8 THE DEA LOG FILE 3.9 THE DEA KEY FILE 3.10 VALID DEA KEYS Chapter Four ══════════════════ 4.1 THE DEA ONE-TIME-PAD SIZE SETTING AND INFORMATION CONTENT 4.2 THE DEA UTILITIES - GENKEY, KEYVIEW, MFD 4.3 SECURE TRANSMISSION OF KEYS 4.4 THE DEA AND PRIVATE E-MAIL 4.5 DEA CIPHERTEXT CORRUPTION Chapter Five ══════════════════ 5.1 THE OPERATING SYSTEM 5.2 DATA SAFEGUARDS AND THE INTEGRITY OF DATA 5.3 PRE-DEA FILE COMPRESSION 5.4 COMPRESSION OF DEA CIPHERTEXT 5.6 DEA v.2.00 ENCRYPTION TIMING TESTS 5.7 MULTIPLE ENCRYPTION AND PRACTICALITY Chapter Six ══════════════════ 6.1 PREVIOUS VERSIONS OF THE DATA ENCRYPTION ALGORITHM 6.2 COVERT AND PRACTICAL CRYPTANALYTIC TECHNIQUES 6.3 DATA ENCRYPTION AND THE LAW 6.4 THE DEA ADVANCED COMMERCIAL VERSION - DEA ACV v.2.00 6.5 DEA PROBLEM REPORTS Chapter Seven ══════════════════ 7.1 PRELUDE TO THE DEA SECURITY ANALYSIS 7.2 THE DEA v.2.00 SECURITY ANALYSIS Chapter Eight ══════════════════ 8.1 REGISTRATION AND ORDER FORM 8.2 DEA USER FEEDBACK 8.3 THE DEA v.2.00 OPERATING SPECIFICATIONS Chapter Nine ══════════════════ 9.1 THE DEA v.2.00 FILE SIZE DOUBLING PROBLEM Additional Information ══════════════════════ APPENDIX ════════ TIMING FUNCTION ERROR MESSAGES WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED? DEA COMMERCIAL VERSION CLEARING THE INTERNAL KEY DATA STRUCTURE A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE ANOTHER METHOD OF CREATING THE DEA KEY PROGRAM EXIT CODES - DEA.EXE only - ACKNOWLEDGMENTS ═══════════════ Chapter One ═════════════════ 1.1 PURPOSE OF THE DATA ENCRYPTION ALGORITHM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The Data Encryption Algorithm, hereinafter referred to as the DEA, is an algorithm designed to protect and maintain the privacy and confidentiality of today's electronic computer data. It is a software tool to be used whenever and wherever privacy must be maintained in personal computer MS-DOS(tm) information files. The information security strength of the DEA far exceeds any of today's cryptographic software tools, including the popular RSA hybrid public key encryption systems. The DEA is a very serious cryptographic tool for serious information security applications. The DEA v.2.00 incorporates the most advanced cryptographic designs ever to be released into the private sector. As you read this document, you will gain an understanding and appreciation of cryptography, its principles, its applications, and its limitations. While no encryption algorithm can provide an absolute and eternal blockade to the original plain text, the DEA has been designed to offer both extremely high security along with ease of use in a compact easy to use package. Data encryption in the modern information age is the cheapest and most convenient method of handling sensitive computer data. It provides unrestricted access to authorized personnel, while providing true security to all others who's business is snooping about for secrets. 1.2 SUMMARY OF FEATURES OF THE DATA ENCRYPTION ALGORITHM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Below are listed the main features of the DEA v.2.00: o an extreme level of security far beyond the 16 year old DES standard, including the new 128 bit key IDEA(tm) cipher and double-length DES keys o 1,440 bit (180 byte) key o the actual key is not used directly as with other common algorithms o sophisticated Cipher Function unlike any previous cipher design o all relationships between plaintext and ciphertext completely eliminated o has the capability of creating ciphertext carrying zero information bits o is extensible to meet future needs via extendable keys & keyspace o user definable operating speed to match your computing hardware o extremely large keyspace which can be extended even further o very easy to operate o may be operated in either command line mode, or interactive mode o can be used with batch file processes o a near one-time-pad implementation without the fuss & mess of the OTP o a completely new and unique key structure which cannot be memorized o integrated automatic military wipe to permanently erase all plaintext o automatic processing file clean up o error checking and detailed error messages o full error trapping and error exit codes o automatically updated program log file o key ID eliminates the need to physically type the key by the operator to help in minimizing TEMPEST electronic signal emissions o ASCII DEA key text may be embedded into files before they are encrypted o DEA default and user-priority file naming conventions o can be used on all MS-DOS(tm) files, including hidden & system o user selectable one-time-pad size o separate utility to generate new DEA keys o separate utility to extract and view existing keys in ASCII format o commercial version's effective keyspace is 2^2,304,000 or 256^36,000 ** in depth general analysis and discussion of cryptology ** security proof disadvantages x can become very slow with large OTP settings x REQUIRES FAST HARDWARE, NO PC /XT support x will double the size of the input file, forcing the use of a file compression utility prior to the DEA x keys are long and cannot be humanly memorized x the DEA is not self-synchronizing; if DEA ciphertext is deliberately tampered with, then recovery of further plaintext will not be possible x conventional key distribution problems apply, as the DEA is not a public key cryptosystem 1.3 SYSTEM REQUIREMENTS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ o For IBM PC AT, and other systems (80386, 80486, and Pentium(tm) ) FAST (33Mhz +) 386 or 486 processor HIGHLY RECOMMENDED o 128K memory o one or two floppy drives, 1.2MB, or 1.44MB and / or a hard disk, OR ANY external storage device accessible by a DOS file pathname o MS-DOS 4.01 or higher o any type monitor x will NOT function with PC XT systems 1.4 THE DATA ENCRYPTION ALGORITHM - QUICK TECHNICAL OVERVIEW ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA is unique in that it is neither a transposition, nor a strict substitution based algorithm, although it is more correctly considered to be a substitution type algorithm. The DEA is a one-time-pad cipher system which comes as close as possible to a true one-time-pad system. A true OTP is one in which the key is as long as the message itself. However, for practical reasons, the one-time-pad ideal is simply not ideal in real world applications. The one-time attribute of the DEA stems from the fact that the DEA never uses the same piece of key information twice. Further, the DEA does not cryptographically combine the plaintext with the key in any manner. The DEA's ciphertext will resist all attempts to correlate known plaintext with corresponding ciphertext. Any such attempts will fail because the DEA ciphertext output is as variable as the plaintext submitted to the algorithm, thus even dictionary type attacks will result in failure. There exists no method whatsoever to derive either plaintext or key information from an examination of the DEA ciphertext. The DEA keyspace in version 2.00 is set at a maximum of 256^180, or 2^1,440 which is 25.714 orders of magnitude larger than the DES algorithm. The design of the DEA allows for an even larger keyspace of practically unlimited length. As a side note, the DEA's total number of keys is represented by a number of more than 412 digits. Compare the keyspace of the DES at 72,057,594,037,927,940. Registered users can expect a keyspace no less than 2^2,304,000 or 256^36,000 which is 41,142.857 orders of magnitude larger than the DES. It is important to state here that while the DEA is extremely secure, it is not unbreakable. The only avenue available to breaking the DEA is by the brute-force strategy of trying all possible keys. Despite this sobering fact, users should not be deterred in using the DEA. Any claim that a particular cryptographic system "is unbreakable" is a deception of fact; such a claim is a naive assertion on the part of the designer to pat himself on the shoulder for his nearsighted accomplishment. Cryptography cannot supply an eternal, forever information blockade. It can, however, provide a 'time lock' barrier. Indeed, cryptography is the next best alternative to completely deleting the information. The DEA is a slow algorithm because it must generate a one-time-pad for each and every 8-bit byte it will process. If our input file, for example, is 1000 bytes long, and the user has selected a one-time-pad size of 10,000 digits, then when the DEA is finished, it will have computed a total OTP of length (10,000 x 1,000) + (10 x 10,000) = 10,100,000 digits. The one-time-pad size of the DEA can be adjusted by the user from 1300 to 20,000. Be aware, however, that the larger the OTP, the slower the DEA will operate. There is, however, no real difference in security provided by the DEA with different one-time-pad lengths. That is, an OTP of 1,500 digits will be just as secure as an OTP of 15,000 digits; the only differences are in processing time, and meaningful information bits within the ciphertext. Larger OTP settings will drastically decrease original information bits, while smaller OTP settings will increase speed and increase the information bits from plaintext to ciphertext, although those bits will be scrambled. Thus, you can adjust the DEA speed to match the type of computing hardware you have, and the size of the data file to be enciphered. Perhaps the most unusual aspect of the DEA key is that it is not used directly. All other systems which employ a key, use it directly. That is, they combine the key with the plaintext via some algorithm. Even the well respected RSA directly combines the key with the plaintext leading to a certain type of ciphertext attack. Whenever the key is combined directly with the plaintext in this manner, very subtle relationships between key and plaintext can be shown to exist. This is what the cryptanalyst is trained to seek out and exploit; it is his bread-and-butter. The DEA must first go through two (2) stages of key translation per file block. Reversing the two translations is not possible. It is only after these two key translations that a useable one-time-pad is created and used by the Cipher Function to encrypt the data. 1.5 WHY USE THE DEA AS AN ENCRYPTION TOOL TO PRESERVE PRIVACY? ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA is the only currently available encryption algorithm for the MS-DOS(tm) personal computer environment which comes as close as possible to the ultimate one-time-pad cipher ideal without the impractical and cumbersome consequences implied by the one-time-pad system. The DEA far exceeds the industry standard DES algorithm in cryptographic strength, while the mathematics of the DEA imply that it is, at least, on an equal footing with the RSA algorithm, if not more secure than this popular public key cryptosystem. Although the RSA is intuitively thought of as an extremely secure cryptosystem, it is not so because no one uses it in its 'native' mode. That is, the RSA system is commonly used as a hybrid system wherein a RSA key is used to encipher a fast conventional cryptosystem session key. It is actually, another completely different encryption algorithm which encrypts your data, not the RSA. The RSA only encrypts the key you used to encrypt the actual file data with the other algorithm. In the popular freeware PGP v. 2.00 by Philip Zimmermann, the file data is enciphered by the IDEA(tm) conventional 128-bit key cipher, and not the RSA. The RSA of PGP v.2.00 only encrypts the 128-bit session key, not your sensitive data. The attentive reader may wonder, then, what the advantages of such a hybrid system may be. In such a design, there are only 256^16 total keys available. This is only 8.89% of the total DEA v.2.00 keyspace. Hybrid RSA systems do offer a viable solution to the problem of key distribution, especially people you have never met. This is a problem with the DEA design. However, even digital signatures of the RSA can pose authentication problems. Thus, hybrid RSA systems are only as secure as the fast enciphering algorithm, in the case of PGP v.2.00, the security derives from the IDEA(tm) cipher. All other services and capabilities of such hybrid systems derive from the RSA algorithm shell. The DEA software package provides you with all the most advanced software tools available to manage your information effectively, cleanly, compactly, and without worry. The DEA is an extremely secure and strong algorithm because its ciphertext will resist any and all attempts to derive algorithm dependencies which could result in successful cryptanalysis. Further, the DEA's keyspace is extremely large, far larger than all other algorithms in common usage today. Since there are no analytic shortcuts available in the DEA v.2.00, the potential attacker is obliged to undertake the method of last resort: brute- force. The algorithm's Cipher Function is the main fortress of security as it shapes and defines the many cryptographically interesting and unique features of the DEA. The DEA incorporates many truly unique designs never before used in cryptography. The DEA represents a complete departure from traditional cryptographic designs. It is surmised that the DEA design will bring about a new modus operandi with regard to how future cryptographic systems are designed. While Personal Computer users have had their pick of the many information security tools available, there has been very little creativity in the way of fresh cryptographic ideas which can stand on their own, and stand up to close scrutiny. The DEA v.2.00 which you are now reviewing, embodies very advanced technology in an easy to use and user-friendly environment. The DEA represents an investment of approximately twenty three (23) months of research, design, and programming. It is definitely not 'snake oil'. The DEA evolved into its present form; it is a transcribed work from v.1.00. Most of the available PC software encryption tools evaluated, do not state explicitly the precise nature and operating characteristics of the algorithms, let alone a proof of the security provided by merchants of such products. The typical approach of many such companies is to either implement the standard DES algorithm in a new user friendly reincarnation, or to develop their own proprietary algorithms which are usually faster and less secure than even the DES. If you have reviewed numerous Shareware encryption packages, you will notice that they are basically cut from the same ideological cloth. You, as the end user, can make a preliminary judge- ment by examining the length of the key. The longer, the better, up to a point. Next, you should examine the way in which the ciphertext itself is created. If the plaintext bits are combined directly, in any manner, with something the algorithm produces as ciphertext, then the cryptanalyst has a job. It is very important for both end users and crypto software developers to avoid a false sense of security. Over zealousness on the part of a software developer can be inspired in users of such systems which claim to be "unbreakable". Nothing could be further from the truth! Any crypto system or algorithm can be broken in theory, including a one-time-pad. The one-time-pad makes things extremely difficult, but still not impossible. If the algorithm defends the information for the time span in which the attacker could gain a monetary, informational, or other advantage, then it has done its job respectfully. The best cryptosystems are those whose ciphertext cannot be used against the algorithm itself by a cryptanalyst. If all relations between plaintext and ciphertext are successfully broken by an algorithm, then there is no other option available save a brute-force attack. This property along with a vast keyspace are the two main features which are the hallmarks of a respectable cryptographic system. The DES was such a system sixteen (16) years ago, but both intense research and computing speed advances have resulted in an algorithm which 16 years later should not be used to protect anything more sensitive than a love affair. In fact, 16 years after the DES was commissioned into service, it can today be broken routinely in less than 24 hours via brute-forcing the algorithm. In the 1990's the DES is also succumbing to new analytic techniques. Today the DES is entrenched in business, government, personal, and corporate affairs; it does the job. It is vital to understand that cryptography is only a component of an overall procedure designed to maintain information security in the information age we all live in today. Clearly, the data encryption standard of yesteryear cannot be relied upon today for high security applications. When choosing an information security tool, the evaluation should comprise some of the following questions: 1. how much security do I need ? 2. what level of security does the information deserve ? 3. what are the possible consequences of security breach ? 4. who most likely poses a latent threat, and what resources do they have on hand ? 5. how much time am I willing to invest in the protection of the information ? 6. is the information security tool itself reliable and does it provide adequate and time-proven security ? 7. how long must the information be maintained private and confidential ? 8. what would the consequences be if I cannot recover the information myself ? 1.6 THE PURPOSE AND USE OF CRYPTOGRAPHY ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Today, with the availability and widespread usage of personal computers in the home, business, and government environments, along with the popular growth of information services such as electronic bulletin board systems (BBS's), there is a growing need to understand what types of data should be considered sensitive, and what measures should be taken to ensure sensitive data is maintained in a confidential state. Cryptography is the science dealing with the transformation of plain and intelligible information into the exact opposite, that is, information which seems to be gibberish. However, the information is not gibberish, it has simply been made to look like a meaningless jumble of now useless information. The goal of cryptography is to render the meaning contained in natural language into a new 'language' which cannot convey meaning in natural language. For example, you might want to take a meaningful English sentence and have it translated into several other languages. Now, the meaning of the sentence exists in several languages, but because we are unfamiliar with these languages, the message is no longer intelligible; these other languages convey meaning, but not to us; and so it is with our intent here: cryptography is the art of translation into meaninglessness. Cryptography deals with the many ways in which the entropy of the information can be modified such that order, structure, and patterns of natural language can be translated into disorder and randomness. Thus, encryption is the overall process of encoding plain information (the plaintext) into a new form which disguises and hides the intelligence of the message (the ciphertext). The intelligence of the message is preserved, but now the intelligibility of the message is lost. However encryption is a reversible 'reaction', that is, the intelligence of the message can be recovered and therein lies the utility of cryptography and the process of enciphering data: it preserves the intelligence of the information while cloaking it in an envelope of meaninglessness for those specifically not meant to see it, just like placing a lock on a box, or a letter into an envelope. In modern times, cryptography is intimately involved with the vast production of information by governments, military affairs of nations, and to a lesser degree, in banking, industry, and commerce. The application of the principles of cryptography today extend far beyond the necessary and logical use by Julius Caesar. Today, cryptography has extended to encompass military satellite transmissions, television, speech, facsimile machines, and the cellular telephone. In short, the dramatic rise of cryptography is directly attributed to the enormous volumes of information we all use and generate on a daily basis. We are, after all, in the information age. And in this information age, we must develop the habit of recognizing what type of information is confidential, and to preserve the confidentiality of sensitive information, we are obliged to use tools which operate upon this information, specifically, we desire to maintain the intelligence of the information while destroying its intelligibility. Although great strides have been made in man's quest for information privacy via a great variety of cryptographic techniques, the basic idea behind this science has remained unchanged from Caesar's day. His need then was the very same as our need today. The only difference is that we use a great number of electronic information interchange devices. 1.7 VARIETIES OF CONFIDENTIAL INFORMATION ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The following listing should help users recognize and decide what types of information merit privacy and deserve confidentiality. 1. any information you wish to MAINTAIN, but NOT SHARE with a particular set of other people for whatever reasons ( *** THE MOST ABSOLUTE AND FUNDAMENTAL REASON FOR THE EXISTENCE OF THE SCIENCE OF CRYPTOGRAPHY. *** ) 2. company employee data files containing: - medical records - salary records - absenteeism records - other personnel records such as drug dependencies, alcohol counselling, family matters, legal matters, etc. 3. any situation in which space is shared with others whose honesty, trustworthiness, and integrity has not fully been ascertained 4. company information, such as: - company information transmission from branch-to-branch - negotiating position - internal operating procedures, or private policy statements - proprietary data, industrial trade secrets - sensitive sales information - company employees operating in foreign nations - legal matters - financial matters - illegal business activities - results of research work - business plans and budgets - manufacturing process - secret formulas (for example, Coka Cola, Kentucky Fried Chicken) - new product developments - future plans / expansion - identity of customers and their purchases - violations of government regulations - information on competitors - membership lists 5. two or more people - two lovers - an organization of peoples with a common goal, perhaps not compatible with others - situations where the content and context may be offensive to others 6. General areas of human endeavour where encryption is used: - government (budgets, internal memos, secret projects, reports, etc.) - military communications - banking (money transfers) - private sector industry and commerce - communications - consumer electronics (your personal organizer, etc.) - education (grading results) 7. Confidential medical records - patient medical records - medical test results 8. Law Enforcement - Secret Service 9. Geological - survey data (such as oil, mineral, gas) - historical data, for example, previous land usage 10. professionals with sensitive client information, such as: - doctors - psychiatrists - lawyers - accountants - auditors 11. Social and behavioral professionals who have collected sensitive data and are concerned about the subjects' right to privacy. (example: subjects of Masters and Johnson studies) - psychological evaluations: your visit to the 'shrink' 12. Individuals who want to maintain the privacy of their own personal information and / or affairs, such as electronic diaries or personal journals whose contents may prove embarrassing if left unprotected. 13. Computer users who routinely transmit and receive sensitive information over insecure public communications channels, for example, routine FAX MAIL, or E-mail 14. Information services such as computer bulletin board systems who desire to maintain confidential member information 15. Writers who submit articles via electronic systems 16. politicians (the Watergate Hotel scandal) 17. any information which could reasonably be expected to result in, or have negative connotations if it were disclosed to a general audience, or at an inappropriate time. 18. negative credentials / reputation Chapter Two ═════════════════ 2.1 GETTING STARTED WITH THE DATA ENCRYPTION ALGORITHM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ After you have uncompressed the DEA201.ZIP archive into a subdirectory on your hard disk, you are ready to run the DEA and the associated utilities. A suggestion is to create a DEA specific directory name such as 'DEA201' and place all DEA files into this directory. Later when you have become accustomed to the DEA, you may wish to add the DEA directory to your PATH environment variable. This way you can have DOS find the DEA executable files from any directory or drive. 2.2 INSTALL.BAT AND SETTING THE DOS PATH ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ If you would like to have all DEA related files placed into the C:\DEA201 directory, you should run the INSTALL batch file. It will copy all DEA files after they have been uncompressed, to the C:\DEA201 directory, where you will then be placed. The INSTALL program does not automatically add the 'C:\DEA201' path to your PATH environment variable as you may not have sufficient environment space available. Simply type a semicolon (;) after the last PATH entry, and enter the path to the DEA directory. Use the DOS SET command to view your environment variables, if you don't know how your PATH is defined. Suppose your PATH variable looks like this: C:\;C:\WRDPFT;C:\WINDOWS If you decide to add a path for the DEA programs, you would issue the following command in full: PATH=C:\;C:\WRDPFT;C:\WINDOWS;C:\DEA201<now hit enter> ^ ............type all this...........^ We placed a semicolon after 'WINDOWS', and added the path for the DEA. When you wish to add other directories, you would place a semicolon after 'DEA201' and follow this with the new directory. When setting the PATH, you must type out everything from the left 'P' to the right '1'. 2.3 RUNNING THE DEA FOR THE FIRST TIME ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ If you are in the appropriate directory, you can now run the DEA by typing its name, DEA <enter>. The DEA will display its sign-on banner along with the program's usage syntax as follows: The Data Encryption Algorithm, DEA Release v.2.01 Copyright (c) 1993 by Nellis du Maurier Information Security All Rights Reserved ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Syntax: DEA {/I} [[/E] [/D]] /K[n] /OTP[n] in_file_name [out_file_name] [<R] Cipher Directives: /E - encipher /D - decipher Operating Mode: /I - force interactive prompt mode <enter only: DEA /I> Numerical Arguments: /K[n] - reference DEA key ID number [n] /OTP[n] - select one-time-pad size: 1300 - 20,000 Files: in_file_name - must always be specified in full [out_file_name] is optional for /E directive only Redirection: <ASCII file containing path spec. to DEA.KEY file Example: DEA /E /K5 /OTP7500 C:\BUSINESS\BIZ-PLAN.DOC C:\FAX_MAIL\MARSHALL.DEA DEA /D /K1 /OTP3971 ISABELLA.DEA The DEA always requires a minimum of four (4) command line parameters, or one (1) when selecting (I)nteractive mode. Please note that the DEA will NOT operate with PC XT class computing hardware. This includes the 8086, 8088, and the NEC V20, and V30 chips. The microcode instructions within the file DEA.EXE are designed for the Intel (tm) 80286 processor. All later Intel processors such as the 80386, 80486, and Pentium (tm) have 80286 code emulation; they can all run the DEA software. 2.4 LEARNING TO USE THE DEA VIA AUTOMATED BATCH FILES ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA software package provides several automated batch files along with several .TXT files to allow you to test the DEA on files before you advance on to your own files. This will allow you to learn the DEA command line effectively and without fear of losing critical data. The batch (.BAT) files are designed for teaching purposes, and if you are impatient to give the DEA a whirl, then it is suggested you run them first, before you do anything else. The batch files will only operate with files supplied with this package; when you have mastered the DEA's command line switches, you may delete them, or replace them with your own to allow you to automate your daily information security chores. You may run the LEARN.BAT file to see how the DEA handles file naming and the DEA command line format. 2.5 THE DEA COMMAND LINE SWITCHES ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA provides for seven (7) command line arguments, which are explained next. Switches are case insensitive; you may use either uppercase or lowercase, as you prefer. /E - directive to encipher a DOS file /D - directive to decipher / decrypt a DOS file /K[n] - select DEA key identification number /I - force DEA into (i)nteractive menu-driven mode /OTP[n] - select one-time-pad size [n]: 1300 - 20,000 The first two commands are intuitive. The DEA's interactive mode is activated from the command line by DEA /i, or DEA /I If anything else is entered along with /I, it is ignored, and the DEA starts in menu driven mode. Interactive mode is not used in the batch file examples. If you experience problems with the DEA in command line mode, then you still have this option available which should work. The /K[n] switch specifies which DEA key will be referenced. Valid examples are: /K1 or /K17, etc. There is no space between the 'K' and the number. The command line switch /OTP specifies the size of the DEA's two internal one-time-pads. The one-time-pad size can range from 1300 to 20,000 digits. Any values outside this range will be rejected. The recommended range for the one-time-pad size is 2,000 to 8,500. The reasoning behind these values is time and user tolerance. Later, we shall discuss the technical considerations involved in selecting the OTP values. NOTE: THE ABSOLUTE MINIMUM REASONABLE OTP VALUE IS 1,300. DO NOT USE ANY VALUE LESS THAN 1,300. Thus, in general, the DEA command line is as follows: DEA /E /K3 /OTP2000 DIARY.TXT This is the most basic format of the DEA command line. The proper ordering of the commands must be observed, however. Note, also cases where you are required to supply a numerical argument: /K[n], and /OTP[n]. Here, there are no intervening spaces; that is, you must enter /K5 and /OTP2000, and not "/K 5", or "/OTP 2000". IMPORTANT NOTICE: ******************************************************* * USE THE SAME OTP SETTING FOR BOTH /E & /D * * * * You must use the same OTP[n] value for encryption & * * decryption, along with the same key ID number, * * otherwise THE FILE WILL THEN BE LOST PERMANENTLY. * * ----------- * * THIS TRANSIENT ERROR NEED ONLY HAPPEN **ONCE** WITH * * DEVASTATING CONSEQUENCES. * * * * ALWAYS check your DEA.LOG file FIRST if you are not * * certain of the correct setting. This also applies * * to the key ID number. Another tip here, is to make * * a working copy of the DEA enciphered file first, * * copying it to another directory to have a back up. * * ....................................................* * SERIOUS INFORMATION LOSS MAY RESULT WHEN THE DEA IS * * PROVIDED WITH VALID BUT INCORRECT INFORMATION. * ******************************************************* In interactive mode, you will be prompted for all the information the DEA requires to process your request. Following the /OTP[n] directive is the DEA input file name. This is the file you wish the DEA to operate upon, either Encrypt, or Decrypt. The [out_file_name], if given, is only used during encryption; it has no effect during decryption. Note also that when decrypting, you must specify the full file name including the file's extension, if any. For example, "ARYAN.DEA", not just "ARYAN". The DEA makes no assumptions regarding the input file's extension at any time. NOTE: ******************************************************************** When selecting the /D (decryption) option, the DEA requires only an input file specification, the output file path, if supplied, is ignored. Instead, the output file path is stored within the DEA file itself; you do not need to specify it explicitly; the original file is restored to its exact same path location before encryption. ******************************************************************** Chapter Three ═════════════════ 3.1 DEA DEFAULT FILE NAMING CONVENTIONS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA allows the user two (2) options when choosing file names for output. The user must supply the full name of the input file, while the DEA will either default to its own file naming conventions, or will abide by the user's file name choices. This default file naming applies only to the DEA output file name. This characteristic behaviour is only active when the DEA is placed into encryption mode from the command line. Below we shall look at representative input and output file names. input file name replaced with --> output file name --------------- ---------------- 1. D:\A04-1993.LB D:\A04-1993.DEA 2. JULIA.TXT (current directory) JULIA.DEA 3. C:\MEDICAL.TXT C:\MEDICAL.DEA 4. C:\WORK\SAMANTHA.TXT C:\TELEMATE\SEND\SAMANTHA.MSG 5. C:\JUNK (file name, not directory!) C:\JUNK.DEA 6. D:\PLAN.DOC C:\BUSINESS\MARSHALL.PRV In general, if the input file is a valid DOS file path, then the file path will be used for the output file path with the extension '.DEA' if only the input file was specified. (1,2,3,5) In this manner, the input file is replaced with its enciphered equivalent. If the input file does not contain an extension, the extension '.DEA' is appended to the file name if only the input file was specified. (5) If the user supplies both an input file name and an output file name, then the DEA will use the user's file specification. This is known as user priority file naming. In this case, if the input file name does not contain a file extension, then none is appended, as the user has supplied his / her own output file name, the DEA will use the user's file name specification. Even if the input file contains an extension, the output file may or may not contain any extension; this depends entirely upon the user's output file specification. (4,6) It will be helpful to remember that DEA files need not necessarily have the extension '.DEA'. You can direct the DEA to create any file name you wish for the DEA output file. This is the reason why the DEA makes no assumptions about the input file name. However, for consistency, you should adopt this practice. If you prefer to specify only the input filename, then the DEA will always give the file the '.DEA' extension. This applies only to DEA command line usage, not to interactive mode. When the DEA is used in interactive mode, and decryption has been selected, the DEA will not query for the output file name, as the output file name is stored within the DEA enciphered file, this name will be used. Note that file conflicts and information loss may result when an input file name's extension is '.DEA' and the DEA is enciphering and the output file name will have the '.DEA' extension also. This is an obvious name conflict of which you should be aware. The DEA does not check for these subtle potential errors, it is your responsibility. 3.2 DOS FILE TYPES & FILE ATTRIBUTES ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA can operate upon any type of MS-DOS(tm) file. All files may be categorized into two main types: ASCII and binary. The DEA operates with all files, regardless of type. DOS files may have one or more file attributes set. The DEA will terminate only if the READONLY attribute is set. If the input file is hidden, or has its system attribute, or both set, the DEA will accept the file, provided that the path to the file is indeed valid. However, with files who's attributes set as such, the DEA output file will not have these attributes set and will, therefore, be displayed by the DOS 'DIR' command. 3.3 THE DEA.KEY FILE LOCATION ERROR ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA key design minimizes TEMPEST attacks via the manual typing of the key during encryption or decryption. The operator is also prevented from discovering the actual key data by usage of the DEA key ID number. The last concern regarding key security, is keeping the key(s) physically away from the computing equipment. The only time the DEA key should be available to the program(s) is when they are required. While this may not be completely convenient, the DEA provides every reasonable avenue to allow the programs to access the key file. All these methods encourage users not to store the DEA.KEY file within their computers. The DEA provides for a number of different methods of accessing the key file as discussed below. If the DEA cannot locate the DEA.KEY file, it will display an error message without terminating. This is a serious error, however the DEA will prompt the user for the path to the DEA.KEY file. If this situation arises, you should enter the full path to a known drive and / or directory plus the name "DEA.KEY" for the file name where this file normally resides. If the path is still incorrect, then the DEA will terminate. This error occurs most commonly when the user moves about in the directory tree and invokes the DEA from a directory other than where all DEA specific files are located. If you have set your PATH environment variable to allow DOS to find your DEA files, you may then invoke the DEA from any directory or drive, but the DEA will not successfully locate its key file, as it looks only on the current directory. This may prove cumbersome at times, as it interferes with automated DEA batch procedures. The basic thing to remember about the DEA.KEY file is that regardless of where you are in your directory tree, the directory you are currently in when you invoke the DEA, is the directory scanned for the DEA.KEY file. However, there are several ways in which this situation can be remedied as follows: 1. place all DEA files in a directory such as C:\DEA. Now, whenever you want to employ the DEA, move into this directory, either by hand, or by a batch file to help avoid the tiresome DOS path typing. Once in the directory, use the DEA as you normally do. 2. As above, but the C:\DEA directory does not contain the DEA.KEY file, instead, the file is located on a removable floppy drive A:\, or B:\. Assuming your PATH is set so that DOS can find your DEA executables, you would now go to drive A: for example, and invoke the DEA. The DEA will load from the C:\DEA directory, but because you are now on drive A:\, the DEA will search the A:\ root directory for the DEA.KEY file. Since it is indeed there, the DEA will operate normally. * This method is preferable because it involves physical security directed over the DEA.KEY file, that is, the DEA keys are not physically to be found in your computer system, they exist separately and outside the system. This is called Key Management, and is a very real concern for serious computer information security. 3.4 ADVANCED METHOD OF LOCATING THE DEA.KEY FILE VIA THE DOS REDIRECTION PIPE ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ This method is preferable over the two methods outlined above as it is able to maintain discreet key management along with automated DEA batch file operations. You will find this technique very helpful in keeping the DEA.KEY file out of your computer system, and thus greatly enhancing your overall information security. Below, we discuss the DOS redirection method and then illustrate several DEA command line examples: DOS redirection symbol used: < meaning information coming into a program Suppose, you wish to have the DEA.KEY file reside on a 1.44MB floppy disk and you want the DEA to be able to locate this file without explicitly instructing the DEA where to find it each time you run the DEA. step 1. Create an ASCII file, preferably on your hard disk, say the root directory like C:\ for example. From DOS, give this command: copy con DEA_PATH step 2. what we want to do now is to create a file which contains a DOS file path to the DEA.KEY file. Since we decided that we want the key file to be on the root directory of drive A:\, we type in: "A:\DEA.KEY" (do not put the quote marks when you actually do it) step 3. Press F6, you will see ^Z, then hit <enter> We have now created a file named DEA_PATH on the root directory of drive C:\ which contains the ASCII text: "A:\DEA.KEY" (no quote marks!). Of course, the file name DEA_PATH is just for illustrative purposes here, you could have chosen a name such as "DP" only, the shorter, the better, as it saves keystrokes if manually entering the DEA command line. However, it is suggested, you use the name DEA_PATH, to easily remember it. Also place this file on the root directory of your hard disk where it can be most certainly found by the DOS PATH variable. If you are using a word processor, then save the "A:\DEA.KEY" text to an ASCII file, that is, without control characters and such. And now, lets see how we use this redirection in a real DEA command line, remember that you are now out of the DEA directory, the DEA directory does not contain the KEY file, it is on the root directory of drive A:\. However, DOS can find your DEA executables, therefore we issue such a command as the following: 1. DEA /E /K2 /OTP1993 C:\JULIA.TXT <C:\DEA_PATH 2. DEA /E /K2 /OTP1993 C:\JULIA.TXT B:\LETTERS\TO_SEND\LOVE.DEA <C:\DEA_PATH 3. DEA /D /K2 /OTP1993 C:\JULIA.DEA <C:\DEA_PATH ---------------------------------------------------------------------------- {switches} {input} {output file path} {redirect} -optional- first second third last The DOS redirection symbol '<' and the directive '<C:\DEA_PATH' must be the last command on the command line (either from DOS, or in a batch file). The <C:\DEA_PATH tells the running program to use the information in the file DEA_PATH for the program. Note that you must specify the path (C:\) to the file DEA_PATH, otherwise this will not function. Therefore, to use DOS redirection, the following conditions must be satisfied: 1. an ASCII text file containing only a DOS file path like C:\DEA.KEY, or C:\NELLIS\DEA.KEY, or A:\MARSHALL\DEA.KEY 2. when you use DOS redirection, be sure to tell DOS where to find the file say, DEA_PATH which contains the actual path to the DEA.KEY file itself. 3. lastly, the DOS path specified in the file DEA_PATH must actually be valid and contain the file DEA.KEY ************************************************************************** Redirection Format & Command Synopsis ------------------------------------- <C:\DEA_PATH - last command on the DEA command line < - the DOS redirection symbol, information going into a program C:\ - tell DOS where to find the file being redirected DEA_PATH - ASCII file containing file path directive to the DEA.KEY file ************************************************************************** This method should be preferred if you are using the DEA in a serious information security environment. Note, however that some DOS shell programs which allow other programs to be run from within an environment, may not work correctly when used with DOS redirection pipes in this manner. Note also that the file DEA_PATH, or whatever name you choose to give it, can contain only one file pathname specification to the DEA.KEY file itself. The DEA will not function correctly when the DEA is used in interactive mode along with DOS redirection, that is, the command DEA /I <C:\DEA_PATH will bring up the DEA interactive screen logo, but will seem to lock up. It is actually not locked up, only that the redirected information is interfering with the console (keyboard) programming. If this happens, simply press CONTROL-BREAK together and that should return to the DOS command processor level. Note that with redirection, you are obliged to specify a file which contains the actual path designation to the key file; you cannot simply specify a plain DOS path to the key file itself, as in: "<C:\DEA.KEY", or "<A:\DEA-KEYS\DEA.KEY"; these ASCII file paths MUST RESIDE IN A FILE. 3.5 MAKING THE DEA.KEY FILE READONLY ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ You may want to make the DEA.KEY file READONLY to protect against erasure. If you do, you should be aware that the GenKey utility will fail to operate properly when it attempts to append another key to the file. You could circumvent this problem by temporarily removing the READONLY attribute, running GenKey, then restoring the READONLY attribute when you are finished with GenKey. The DEA will not function correctly if the DEA.KEY file is made hidden and you use the redirection symbol. The problem here is because the file is hidden. In this case, the DEA will stop and ask for the path to the DEA.KEY file, so the hidden attribute on the key file should not be used when it is desired to use the DEA with automated batch processes; it will still work, but its operation will be interrupted. Creating multiple working copies of the DEA.KEY file is not recommended as it may result in serious information loss and security breaches; ONLY make back-up copies to either, or both floppy diskette and paper. 3.6 THE DEA EMBEDDED FILE PATH ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The input file path to the DEA in either command line or interactive mode is embedded in the DEA file so that upon decryption, the original file name along with that file's original contents are completely restored. This design is more than intuitive, it is a great convenience. However, in some cases, the embedded file path may cause some minor problems. If, for example, you have just completed encoding a file and it contains a DOS path, and you now send this file to a friend, your friend's directory tree will probably be different from yours, and thus when he attempts to decrypt it, the DEA terminates, complaining about a non-existent directory path. Here, the DEA is attempting to restore the original file from your directory, to the same directory in your friend's directory structure, but he doesn't have that directory. There are three ways to deal with this. First, your friend may decide that he will just create the required directory, and then try the decryption again. He can also go into the encoded file and eliminate the DOS path specification, keeping just the file name itself. Eighty one (81) bytes of any DEA file contain DOS path and file name information, and may be altered at will, provided that nothing beyond the initial 81 bytes is altered, and that the DEA file is saved with no size modifications. The third method of avoiding this minor problem, is to go directly to the directory where the file you wish to encrypt resides, and invoke the DEA at this directory. Or, copy the desired file to the directory where you are now, and then start the DEA to avoid having the DEA include a full DOS subdirectory path. In this way, when the file is deciphered, it can be placed onto any directory or drive. This release of the DEA does not store the time and date stamp of the original file. 3.7 DEA AUTOMATIC PROCESSING FILE CLEAN-UP ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ W A R N I N G: The DEA completely and permanently erases all input files when the DEA is used in Encryption mode. Although data loss is very unlikely to happen, it is possible, and users should be aware that the DEA will never 'forget' to erase PERMANENTLY and COMPLETELY all traces of the input file when encrypting. The DEA will always 'clean-up after itself'. It will not leave any traces of the original plaintext on the disk media. When decrypting, the encoded file is simply removed by deleting the file's DOS File Allocation Table (FAT) on the current directory only. After encryption, the DEA automatically engages the Military File Deletion algorithm; you will be alerted to this by the audible beeps. The MFD algorithm completely overwrites the original file a total of ten (10) times with an alternating bit pattern. This is nine (9) times more than any other software crypto program would do, and users of the DEA can feel assured that even if their harddisk were sent away to a special data recovery laboratory, there would be no incriminating data to salvage. The MFD algorithm in the DEA is also provided as a stand alone utility (MFD.EXE) so that you can completely and permanently eliminate the data files you don't wish to keep around, without having to run the DEA just for this task. Note that the MFD can also be used with this intention to kill virus infected files so that those known infected files do not add more infection. 3.8 THE DEA LOG FILE ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA automatically creates an new DEA.LOG file in the current directory if none exists, or updates it if it does exist. If you invoke the DEA from several different directories, you will find that these directories contain DEA.LOG files. To avoid this problem, always invoke the DEA from a standard, consistent directory. The LOG file itself contains some data pertaining to decryption, specifically, it contains the OTP settings used for various files plus key ID numbers. This information should be maintained discreetly, just as the key. It should, perhaps, be on the same floppy as where the keys reside. You could have a floppy disk (suggested 1.44MB) with a DEA_KEY subdirectory, along with a DEA_LOG subdirectory on the same floppy. At the end of every month, you could edit the file, deleting log entries which are no longer significant. Another DOS redirection trick works for multiple DEA.LOG files scattered about in different subdirectories. Suppose you decide that your main DEA.LOG file will be kept in C:\DEA. However, you see from the DEA.LOG files that there are log files all over, how can you put all of them into one convenient holding place? Regardless of which directory you are in, after the DEA shuts down normally, the subdirectory will contain either a new, or updated DEA.LOG file. Now issue the following DOS command: type C:\WINDOWS\DEA.LOG >>C:\DEA.LOG Usually, the 'type' command will output a file to the screen, but here, the effect is to append the DEA.LOG file in the C:\WINDOWS subdirectory to the already existing DEA.LOG file in the C:\DEA subdirectory. You may now safely delete the C:\WINDOWS\DEA.LOG file knowing that its contents have been appended to the end of the DEA.LOG file in directory C:\DEA. Of course, the C:\DEA.LOG file will get larger as this is done over time, but it keeps things organized and documented. Remember to use '>>' here, not '<' as we did earlier on the DEA command line. '>>' will, append data, while '>' writes a new file, destroying the older version. You can also create an automated DEA batch process using DOS redirection to take care of daily DEA.LOG files. As mentioned previously, you should also make an effort and get into the habit of backing up the DEA.LOG file. Your firm's Information Security Officer should have close control over the DEA.LOG file. It not only serves to record a DEA 'transaction', but it also contains confidential DEA related records pertaining to each transaction. This is fairly simple to do, and once it is set up as an automated batch process, it is routine and effortless. DOS redirection pipes can be a great benefit here, as they will help to keep things organized and documented at all times. 3.9 THE DEA KEY FILE ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ To use the DEA, you must have a valid DEA.KEY file. As noted, there are several methods available for you to address this file when using the DEA. The DEA is shipped with one DEA key in the DEA.KEY file. The key itself is 180 bytes long, but the actual size of the key file is 240 bytes, the remainder is used by the DEA during processing. With the addition of new keys, the key file will grow by 240 bytes each time, that is 240, 480, 720, 960, 1200, 1440, 1680... The DEA performs a check to make certain that the key file is indeed a multiple of 240. If not, then the DEA will terminate. The total number of keys available is computed thus: DOS reported size of file DEA.KEY is: 2160 bytes. Now, 2160 divided by 240 gives 9. Therefore there are 9 keys available. The total number of keys the DEA can address is 32,767. This means that if your DEA.KEY file's size was 7,864,080 bytes in length, then 7,864,080 / 240 = 32,767 total keys available. It is strongly suggested that you physically keep the DEA.KEY file away from your computer system. Instead, the key file should be backed up to at least two (2) floppy disks, one for daily use, the other serving as protected archive back up copy. A typical 1.44MB floppy disk is very convenient for this; it will be capable of storing approximately 6,141 DEA keys. The DEA v.2.00 does not keep the DEA.KEY file open as it does with other processing files, instead, the DEA will: <1> scan current or specified directory for the file DEA.KEY, <2> open the file DEA.KEY, <3> read the indicated key via the key's ID index, <4> store the key data in internal DEA data structure, <5> close the DEA.KEY file. At this point, the user can safely remove the floppy DEA key diskette from the drive; the DEA will never again need to reference the key file during that session. At the conclusion of the encryption or decryption session, the DEA will automatically delete the contents of the internal DEA key data structure. This assures you that there are no keys or parts of keys floating about in your PC's memory before powering down the system. The name of the key file DEA.KEY must not be changed, since this unique name is encoded into the DEA and the DEA utilities, with the exception of MFD.EXE. 3.10 VALID DEA KEYS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ All keys produced by the GENKEY utility are valid. In cases where the user invokes GENKEY and does not provide all information requested by GENKEY, then GENKEY may or may not terminate with a divide by zero runtime error. Here, the user has not specified all initial prime divisors, but GENKEY has opened the file DEA.KEY data file. If the file is a new one, it has an entry in the DOS File Allocation Table (FAT), but has size zero (0). If the DEA.KEY file already exists and GENKEY terminates with a run time math error, then no data in the DEA.KEY file is disturbed. Note that you cannot use a DEA.KEY file of zero length for obvious reasons. If the user wishes to quickly go through all of GENKEY's numerous information prompts, without actually entering "real" data, then GENKEY will still create a DEA.KEY file, or update an already existing one. But, if you carefully examine the newly created key with the KEYVIEW utility, you will see that typical DEA key information is missing; normally this is shown by zero. If such a "valid" key is used with the DEA, the DEA will terminate with a divide by zero math run time error because the DEA is unable to correctly build the two critical one-time-pads for the system. In general, you can be assured of valid keys at all times if you truthfully supply GENKEY with 'real' and valid data as GENKEY requests. As noted in the section THE DEA AND DATA CORRUPTION, the data in the DEA.KEY file may itself become corrupt somehow and will, therefore, result in an invalid key. Please refer to that section for tips and general guidelines to follow which will make your DEA experience a safe and productive one. Another important note regarding validity of DEA keys is the following. The values specified for the denominators should not be excessively large; they should not be larger than 429,496,729 - 20. Values larger than this value will cause unpredictable results when the DEA is engaged in the production of the two internal one-time-pads. Specifically, this relates to the DEA's mod-mult random feed algorithm. Please note that the DEA does not store any key information within a DEA enciphered file. As a result of this, the DEA program cannot verify keys for you. You can achieve this effect, if you so desire, for periodic key changes via an embedded ASCII Key Change Packet which we shall discuss. This practice in no way reduces the security of the DEA, and is strongly advised to change keys on a periodic basis with all cryptographic tools. As the DEA provides an extreme level of security, the hassle of changing keys frequently can be minimized to a bi-weekly or month-end affair. If the encryption key(s) were embedded in the cipher file, then it would be possible to verify the key by both the program and some attacker wishing to gain access to your data. Some programs have this "feature" built in, but it is not advisable because it represents a serious security breach. With such a situation, the attacker is fully justified in attempting to discover the embedded key from the enciphered file, rather than expending his effort going through 72 quadrillion key combinations. Such encryption tools are nothing more than a plaything; any real security provided by such intuitive design is quickly negated by the strategy of encoding the key into the file. The DEA data encryption package is designed to provide serious information security, not to seriously jeopardize your confidential information. Thus, this capability will never be incorporated into the Data Encryption Algorithm Software Package. Note that DEA keys are 'verified' transiently: if the correct key plus the correct OTP plus the correct DEA ciphertext is submitted to the DEA, and the program produces the anticipated output, then all key information has been verified and there was no corrupt data. Chapter Four ═════════════════ 4.1 THE DEA ONE-TIME-PAD SIZE SETTING AND INFORMATION CONTENT ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA always requires an OTP value, either for encryption or decryption. This value will greatly affect speed performance tests. In general, the larger the value, the slower the DEA will operate. Although you may specify a numerical argument for /OTP[n] in the range 1300 to 20,000, it is best to select an OTP value, for example, which results in a 70 - 30% mix of Stop Addresses to scrambled 8-bit bytes. The IBC counter from command line usage shows the number of scrambled 8-bit bytes (in the form of 16-bit integers) in the DEA ciphertext. This OTP value directly influences the nature of the DEA ciphertext's information content. During command line encryption, the DEA shows two counters, the IBC counter indicates the number of information bits from plaintext to ciphertext. Most cryptographic software tools, including the DES, will have a 100% information bit count in the ciphertext. This means that if the plaintext consists of 80,000 bits (10,000 bytes), then there are also 80,000 bits of information in the ciphertext (without compression). Although the 80,000 bits are scrambled via the agency of some algorithm, there are, nonetheless, 80,000 bits of actual information in the ciphertext. Cryptographic weaknesses will usually be exposed when a cryptanalyst is engaged in the task of examining the transformations when a chunk of plaintext is exposed to the action of a particular cryptographic algorithm. The DEA Cipher Function v.2.00 was designed with the main goal of eliminating the plaintext-to-ciphertext information bridge. The 'bridge' may be thought of as the particular algorithm shuffling the bits in the plaintext to produce the ciphertext; the bit shuffling logic of the algorithm is the bridge. The cryptanalyst's job is to traverse this bridge with an information gap with the aim of using the ciphertext's information bit content to reverse the logic of the algorithm. In other words, the cryptanalyst is trained to seek out the very minute patterns of order in an otherwise entropic environment. The DEA v.2.00 has the capability of squeezing out 99% to 100% of all plaintext information bits. The result of this process, is ciphertext which contains nearly zero shuffled plaintext information bits. There are also other algorithms which have this unique ability to eliminate information bits while replacing them with algorithm dependent output. The RSA is one other such algorithm. With such ciphertext, the cryptanalyst is forced to dispense with a good portion of her / his professional training, and is thus manoeuvered into the position of examining the operating characteristics of the algorithm in question. For most information security applications which the DEA will be called upon, it is not necessary to select the maximum one-time-pad size of 20,000 digits. It would be more practical to select a value between 2000 and 10000. Basically, the faster your Personal Computer is, the larger the OTP settings you can select. It is important to realize that in the majority of cases, the DEA will produce 'mixed' ciphertext. That is, the ciphertext will consist of Stop Addresses along with shuffled plaintext information bits of a variable percentage, depending upon the OTP size setting. There is no real or apparent difference with regard to security provided by the DEA with smaller or larger OTP settings because the DEA's Cipher Function is not strictly defined to operate in a particular manner; the definition incorporates the overall design, but allows flexibility based on the OTP size variable. Furthermore, both the Cipher Function and the one-time-pads operate on a random basis, not pseudorandom. Of course, the design imposes mathematical limits, but this has no effect on security provided by the DEA. IMPORTANT NOTICE: ******************************************************* * USE THE SAME OTP SETTING FOR BOTH /E & /D * * * * You must use the same OTP[n] value for encryption & * * decryption, along with the same key ID number, * * otherwise THE FILE WILL THEN BE LOST PERMANENTLY. * * ----------- * * THIS TRANSIENT ERROR NEED ONLY HAPPEN ONCE WITH * * DEVASTATING CONSEQUENCES. * * * * ALWAYS check your DEA.LOG file FIRST if you are not * * certain of the correct setting. This also applies * * to the key ID number. Another tip here, is to make * * a working copy of the DEA enciphered file first, * * copying it to another directory to have a back up. * * ....................................................* * SERIOUS INFORMATION LOSS MAY RESULT WHEN THE DEA IS * * PROVIDED WITH VALID BUT INCORRECT INFORMATION. * ******************************************************* 4.2 THE DEA UTILITIES - GENKEY, KEYVIEW, MFD ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA Software package includes three (3) utilities to help you to use the DEA effectively. The GenKey utility generates new DEA keys for use with the DEA program. GenKey requires a full pathname to the DEA.KEY file on the DOS command line. Invoking it without a valid pathname produces an error message and GenKey will terminate. You may specify a pathname to any valid drive and directory. Suppose you have a key file located on C:\DEA. Thus, if the following GenKey command line is given: GENKEY C:\DEA\DEA.KEY GenKey will append a new key to the DEA.KEY file in directory C:\DEA. If, however, you specify a valid path, but there exists no DEA.KEY file there, then GenKey will create a new DEA.KEY file in the specified directory. Suppose for example, you issue the command: GENKEY A:\DEA-KEYS\DEA.KEY GenKey will scan the directory A:\DEA-KEYS for the DEA.KEY file. Since there is no such file there, GenKey will create the DEA.KEY file on drive A: in subdirectory DEA-KEYS. If GenKey is given a pathname which does not exist, GenKey will terminate, that is, GenKey will not create the directory if it does not already exist, you must create the desired DOS directories first. In general, if you specify a valid DOS path (with "DEA.KEY" at the end) GenKey will append a new key if the file DEA.KEY already exists in the specified path, or if the file pathname is valid, but there is no DEA.KEY file there, then GenKey will create a new DEA.KEY file in the specified path. Although the GENKEY procedure could have been automated via the use of a random number generator (PRNG), there is a subtle and unobvious reason why this strategy was not implemented. Refer to the APPENDIX for a full discussion of this issue. The KEYVIEW utility is designed to allow you to have a hardcopy of any key residing in the DEA.KEY file. Again, you must provide KEYVIEW with a valid path to the DEA.KEY file on the DOS command line at the time you invoke KEYVIEW. The KEYVIEW command line format is exactly the same as that for GenKey. KEYVIEW will not write anything to the DEA.KEY file, instead, it will write to a file called DEA_KEY.ASC. This file will contain the ASCII textual equivalent of the key's ID number. You may then print this key, or store it in some other manner as you desire. If you have several keys in the DEA.KEY file, and you want to have the ASCII equivalent of all of them, then you must run KEYVIEW several times, each time selecting a higher key ID number (keeps things ordered). All output from the KEYVIEW utility will be placed into the file DEA_KEY.ASC. The file DEA_KEY.ASC will be written on the current directory. Remember that secrecy must be applied to the file DEA_KEY.ASC as it contains actual key(s); it is just as important as your DEA.KEY file itself! It is suggested that after you have printed the contents of DEA_KEY.ASC, or have added it to a key notification change packet, you should then run the MFD utility to remove all traces of DEA's key information from the DEA_KEY.ASC file; there are many subtle little gaps which can occur and may severely jeopardize your information security. The MFD utility is a small handy delete utility. Be advised, however, that MFD will permanently, completely, and irrevocably delete the file. The MFD algorithm is also used in the DEA. After encryption, the DEA invokes its own internal MFD algorithm. The MFD overwrites the input file with an alternating bit pattern a total of ten (10) times before finally removing the file from the DOS File Allocation Table (FAT). If you have several copies of a file in different directories, and you use the MFD to erase one of those multiple files, then only the one specified by you will be erased; the other copies will be not be touched. The MFD utility does not accept DOS wildcard characters; it is designed to operate upon one file at a time only. This is to avoid a potential data loss catastrophe. MFD also requires a file path given on the command line, for example: MFD C:\JUNK.TST MFD LETTER.RYN (current directory) MFD will seem to take a rather long time to delete a file from a floppy disk; this is normal as floppy drives are many times slower than hard disks or ram disks. If your drive light is on, don't worry, MFD is operating as usual, as long as you also see the indicator changing, and MFD beeps occasionally, everything is fine. 4.3 SECURE TRANSMISSION OF KEYS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The KEYVIEW utility is also provided with this package to allow you to have a hard copy of the DEA.KEY file, or a particular key that you desire to communicate to an associate or friend. How you go about this is up to you. You may want to encode the ASCII textual equivalent of, say, key ID #7 into a DEA file which you will transmit either in person, or by modem to the other individual. Suppose you have some text file called THE_BOSS.TXT. You and your acquaintance are assumed to be already using a DEA key which is the same for both people. However you want to signal to your friend, that on the date (x), the following DEA key will go into active service for a total of thirty (30) days thereafter. At the end of the file THE_BOSS.TXT, you would make a note of this changeover. For example, create a file with the contents shown below: ******************************* * DEA Key ID Change * * * * From: J. Francis * * To : R. MacPherson * * * * Date: 09-23-1994 * * * * Invocation Date: 10-01-1994 * * New DEA Key ID: 1 * * New OTP: 5357 * * Expiry Date: 10-31-1994 * <---- file name is: KEY_PAK.ASC * Shipping Date: 09-29-1994 * * * * ASCII DEA key shown below * * * ******************************* Issue the following DOS command in full: type KEY_PAK.ASC >>THE_BOSS.TXT This will now append the above contents of the file KEY_PAK.ASC to the end of the file THE_BOSS.TXT. But, J. Francis not only wishes to advise his acquaintance of the new key, but also wants him to have the new key in ASCII format. Therefore, J. Francis will need to created a new DEA key with the GenKey utility which will be placed into the file DEA.KEY. J. Francis must now extract the new key with the KEYVIEW utility. He can now issue the DOS command to add the contents of DEA_KEY.ASC to the end of the file THE_BOSS.TXT as follows: type DEA_KEY.ASC >>THE_BOSS.TXT J. Francis can now encipher the file THE_BOSS.TXT with his previous key (not the new one, just yet!) and send it to R. MacPherson. When R. MacPherson receives the file from J. Francis, he can decipher it with their previously mutually agreed upon DEA key. R. MacPherson, on the invocation date, will be required to use the GenKey utility and feed it the new key information J. Francis has outlined. Observe that both the key and the OTP setting together, are required for successful decryption; the OTP value is indeed key information. This is all relatively simple, but it is advisable to treat all your DEA.KEY files with respect; normally, new keys are added to the DEA.KEY file by GenKey, to avoid having multiple key files scattered across different directories. With the KEYVIEW utility, you can extract only the specific key you desire to have encoded into a message, like the example given. Caution is advised only in situations where there are multiple DEA.KEY files, for obvious reasons. It is strongly suggested that you avoid multiple key files; this situation can quickly become a terrific headache and even result in very serious data loss. 4.4 THE DEA AND PRIVATE E-MAIL ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA ciphertext cannot be transmitted through electronic mail channels. This also applies to the majority of cryptographic programs because all eight (8) bit permutations are used. E-mail communication channels typically employ a limited ASCII character set which can be sent reliably over diverse networks such as Internet, Compuserve, and others. DEA users who wish private E-mail are directed to employ the UU-encoding, or XX-encoding system. These coding utilities can be used to encode any type of file into a standard ASCII limited character set which can then be sent with reliability over diverse information networks. The XX and UU-encoding strategies will expand the plaintext (whether it is a DEA output file, or otherwise) by 33%. You can use any files with these programs. These utilities may be obtained from various Bulletin Board Systems (BBS's) and are not provided in the DEA software package. Note that both XX and UU-encoding are good for this purpose, but corrupted data may still occur with the encoded file. Such problems may be transmitted on to the DEA file itself when the file is decoded first by UU-decode at the receiving end. If you are concerned about the expansion of text with these utilities, you may wish to consider compression. For example, your private E-mail can be FIRST compressed, SECOND DEA encoded, THIRD UU-encoded, then SENT as E-mail. To function correctly, both the sender and receiver must use the following coding sequences: sender: 1. compress plain message 2. DEA encode the compressed file from step #1 3. UU-encode the DEA enciphered file from step #2 4. send the UU-encoded file as E-mail receiver: 1. UU-decode the E-mail 2. DEA decode the output file from step #1 3. uncompress the file from step #2 4. read your E-mail message Note that as there are several 'layers' of coding involved here, even a single corrupt bit in the final UU-encoded file may upset the other layers, resulting in gibberish. Users will have to experiment a bit first to determine if these utilities can be used in your situation with reliability. In general, if your communications are reliable, then you can use these methods with no difficulties. DEA enciphered files can be electronically transmitted with your communication program just like any other files. For example, a book author like the TV character Jessica Fletcher of "Murder She Wrote" fame, may decide to encode the final manuscript with the DEA and transmit it to her publisher. There are no restrictions with transmission of DEA files. The restrictions apply only to electronic mail systems with abridged character sets. There are no restrictions in using the DEA encoded files with your FAXCARD. 4.5 DEA CIPHERTEXT CORRUPTION ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Any information in a digital device can become corrupted. If the device is 'smart' and contains an error correcting algorithm, data corruption may or may not extend to the encoded instructions responsible for error correction itself. Thus, the term "Error Correction" does not imply 100% safety. The DEA v.2.00 does not apply error correction strategies to the decryption process. Modern day computer data storage media are very reliable. It is advisable, however, to always choose brand name floppy disks; no name disks are actually thinner in diameter and will wear faster. Such disks are not manufactured to the same precise and exacting standards set by well known manufacturers. Any computer file can become corrupted by many different causes: hardware controller failure, media failure, dust, radiation, magnetic fields, plain wear-and-tear, computer viruses, etc. If DEA ciphertext is corrupt, the DEA has no way of knowing this fact. It will process the file with the given key information as usual. If the deciphered file reflects a compressed file, the compression utility will report an error. If the file is an ASCII file, it may not be intelligible. If the file is an executable file, it may not function correctly, or may even hang the computer. When such a problem arises, you will know that the data is corrupt and you should have a close look at possible hardware problems, storage media reliability, and physical media handling and storage practices. Many people operating Personal Computers routinely place their floppy disks beside or leaning against their monitors. This practice, although it may be convenient, should be discouraged. Further, keep important floppy disks away from other magnetic office equipment such as the microphone of telephones. Stringent physical handling and physical storage guidelines of floppy disks should be maintained at home and the office. Information loss need only occur once to remind you that an ounce of prevention is indeed worth a pound of cure. And, in a business environment such careless treatment of floppy disks and their contents may prove embarrassing, time consuming, may result in lost profits, and even in your job. Therefore, if disks are accorded their due respect, then you should not have to worry about data corruption with the DEA. Always perform routine data media maintenance and back up on a regular basis as your electronic information volumes dictate. Data corruption can be of varying degrees of severity. If data is corrupted at or near the beginning of the enciphered file, then all or most of the data is lost permanently. If the data corruption begins at the half way mark of the file, then the last 50% is lost. In general, the point at which corruption begins, is the point at which data is irretrievably lost. Data corruption may also be sprinkled throughout the file in a random manner, in which case, data from the first corrupt data byte to the end of the file is lost permanently. With corrupt ciphertext, the DEA is unable to maintain its correct Cascade Synchronization. This is not a fatal program error but is a fatal information recovery error. And, as noted, the DEA does not check for this error, nor report it. As soon as this internal Cascade Synchronization is disrupted by corrupt DEA ciphertext, the entire delicate balance of the system is completely and irrevocably altered, and the DEA is forever unable to recover thereafter. It should be noted that all computer programs worth their salt which work with data files will not cause data corruption by themselves, data corruption is almost always traceable to a non-program cause, unless the program in question is a computer virus embedded within a program itself, in which case, the cause is still external to the program being used. Caution is advised in multi-tasking environments, as switching back and forth between programs may cause cross linked files. Chapter Five ═════════════════ 5.1 THE OPERATING SYSTEM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA v.2.00 was designed to operate under the MS-DOS(tm) operating system version 4.01+ for personal computers. You may be running the DEA from WINDOWS(tm), DESKVIEW(tm), OS/2, or in a network environment. While the DEA has been designed and tested under DOS 4.01, its operating characteristics, especially the DEA's redirection, may not work completely as documented in these other operating environments. Check your operating system's documentation first, if you are having difficulties. The DEA keeps a number of files open during processing, these files are: 1. the input file 2. the output file 3. the .LOG file *** the DEA key file is opened, read, and then closed at the very start of the program, so that you may remove the diskette containing the key information immediately following normal DEA processing. In multi-tasking environments, keeping a number of files open, then switching to another program with its own set of files, and then going back and forth like this, may end up in cross-linked files. Excercise CAUTION AND BACK-UP your DEA.KEY file to a floppy diskette in both binary and ASCII forms. If you intend to run the DEA under other operating systems, a suggestion is to run the LEARN.BAT file first and observe the behaviour of the program. If everything works fine, then you may try redirection pipes next and see if this works as it should. Consult your Operating System manual if you are running the DEA in a multi- tasking or network environment regarding multiple open files. 5.2 DATA SAFEGUARDS AND THE INTEGRITY OF DATA ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA was designed so that when a file is to be enciphered, its corresponding plaintext equivalent is automatically and completely erased, thus replacing the original with an equivalent file, except that the new file has a 'lock' on it. All that encryption can provide is a 'lock' for the information. We lock our cars, houses, safes, diaries, etc., but how can computer information be 'locked'? By placing the data into a non intelligible form, we effectively exclude everyone from access to the intelligence contained within the information. The DEA's main and primary data safeguard is the automatic deletion of the original plaintext information. Encryption then provides the storage security for the information while the information is en route, or is simply being stored. The integrity of data is not supplied by the DEA in any form. Instead, data integrity is derived from reliable storage devices and media. It is the primary concern of companies involved with the design and manufacture of electronic data storage devices to be concerned with integrity of the data stored on their devices. When you purchase a box of floppy disks, you may notice that the manufacturer claims that the entire recording media has been tested, that it undergoes many more rigorous test than those of the average disk, and that it is guaranteed for the life of the disk. These are things which you, or your firm look for when deciding who's product to buy. Who needs unreliability anyway? Making intelligent choices like this for all your computing needs will greatly enhance the integrity of the data in your computing system environment, whether information is encrypted, or not. It is also your responsibility to periodically inspect, test, and clean your storage devices such as floppy drives for head alignment, read / write accuracy, and read head cleaning. Hard disks should also undergo periodic tests for reliability and defragmentation. These tips and suggestions will go a long way toward data integrity and reliability with all the software packages you use with your personal computer. 5.3 PRE-DEA FILE COMPRESSION ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA's Cipher Function output is a data entity known as the Stop Address. The Stop Address must be represented as a 16-bit entity to preserve accuracy and precision in the DEA system. As a result of this, the DEA will expand the original file's size two (2) times. Thus if the plaintext file's size is 1,000 bytes, then the DEA will output 2,000 bytes of ciphertext. There are many other cryptographic algorithms with this annoying trait. Certainly, this is an inconvenience, but unavoidable. The best method of dealing with this, is to compress the desired file before submission to the DEA with your favorite compression utility. The DEA does not provide automatic input file compression, the user must perform this task manually, or via an automated batch process. Since the DEA operates upon one file at a time, you may find it more convenient to gather up all files you wish to encode, compress them, then submit the compressed archive to the DEA for encryption. This is an organized approach to multiple file encryption since the DEA does not support DOS wildcards. Compression is very useful because it saves space when storing information, and it saves time during the encryption process. When using pre-DEA compression, you should be able to break-even, on average. That is, the doubled DEA output file will usually be less than or equal to the original uncompressed file. Text files will benefit the most from compression. Note that during decryption, the DEA reads the 16-bit Stop Address, and writes an 8-bit byte value to the output file. The extra storage space occupied by the DEA file is released when the file is deciphered to its original state. 5.4 COMPRESSION OF DEA CIPHERTEXT ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA ciphertext can be compressed, but this serves no really useful purpose; it is briefly discussed here in the interest of completeness. As the OTP setting becomes larger, the DEA Stop Address content will rise, thus, both the low and high byte of the 16-bit data the DEA v.2.00 writes as ciphertext contain 'information'. When the OTP setting is set between 1300 and 3000, there will be much fewer Stop Addresses in the ciphertext, and therefore, only the low byte will carry significance; the 8-bit high byte will be zero and carries no information, except bulk. DEA ciphertext resulting from low OTP values are compressible by about 15-24 percent. 5.5 A SHORT LOOK AT THE DEA CIPHERTEXT ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Below, we look at the hexadecimal bytes resulting from the encipherment of 7 bytes of binary zero plaintext with the same key, but different OTP settings: OTP: 959 (Note: OTP was raised later to 1,300 minimum) enciphered bytes: 89 00 C3 00 15 00 D5 00 26 00 56 00 32 00 OTP: 1571 enciphered bytes: CC 03 C7 00 CC 00 0B 04 04 00 22 00 E4 03 OTP: 5000 enciphered bytes: CC 03 B3 0B 13 0A 0B 04 CD 00 D9 06 E4 03 OTP: 10000 enciphered bytes: CC 03 B3 0B 13 0A 0B 04 AB 18 D9 06 E4 03 OTP: 20000 enciphered bytes: CC 03 B3 0B 13 0A 0B 04 AB 18 D9 06 E4 03 Observe that for this data sample, the OTP of 20,000 takes longer than the OTP of 10,000 but produces no ciphertext changes. As the OTP setting increases, the ciphertext will gradually take on a concrete form as shown above. Thus, 03CC is a hexadecimal address, so is 0BB3, etc. Since the DEA ciphertext assumes its most concrete form when it contains 100 percent Stop Addresses, 100 percent Stop Address content is virtually guaranteed by a one- time-pad value of 20,000 digits; there is nothing to be gained by extending the OTP beyond 20,000 digits. Cryptographic security would be the same for an OTP of 20,000 and one of 40,000 digits. 5.6 DEA v.2.00 ENCRYPTION TIMING TESTS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Performed on 80286 PC AT Compatible Operating at 12 MHz Observe that the longer that the one-time-pad becomes, the greater the time requirement, and the decrease in per second throughput. As the OTP value increases, so does the DEA Stop Address content of the ciphertext and the decrease of shuffled plaintext information bits. The advantage of higher OTP settings is the thorough and unrelenting breakage of plaintext-to- ciphertext relationships; this feature of the DEA comes at a price: time. The faster your computing hardware, the larger the OTP settings you can realistically select and use. However, the general timing and throughput statistics given here will be valid for all PC processor types; larger OTP values will slow down even the most powerful 80486, or Pentium(tm) processor. File Size: 154 bytes One-Time-Pad Size: 775 digits Time: 13 seconds Throughput per second: 11 File Size: 154 bytes One-Time-Pad Size: 1000 digits Time: 16 seconds Throughput per second: 9.6 File Size: 154 bytes One-Time-Pad Size: 2000 digits Time: 30 seconds Throughput per second: 5.1 File Size: 154 bytes One-Time-Pad Size: 3000 digits Time: 43 seconds Throughput per second: 3.581 File Size: 154 bytes One-Time-Pad Size: 4000 digits Time: 56 seconds Throughput per second: 2.75 File Size: 154 bytes One-Time-Pad Size: 5000 digits Time: 71 seconds Throughput per second: 2.169 File Size: 154 bytes One-Time-Pad Size: 6000 digits Time: 84 seconds Throughput per second: 1.833 File Size: 154 bytes One-Time-Pad Size: 7000 digits Time: 97 seconds Throughput per second: 1.5876 File Size: 154 bytes One-Time-Pad Size: 8000 digits Time: 110 seconds Throughput per second: 1.400 File Size: 154 bytes One-Time-Pad Size: 9000 digits Time: 123 seconds Throughput per second: 1.2520 File Size: 154 bytes One-Time-Pad Size: 10000 digits Time: 137 seconds Throughput per second: 1.12408 5.7 MULTIPLE ENCRYPTION AND PRACTICALITY ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Some Shareware data encryption software tools reviewed by Nellis du Maurier Information Security are designed around the basis of multiple encryption via different algorithms and / or double encryption. The basic philosophy of cryptography is the design of an algorithm which is extremely secure in one pass over the plaintext. Even the simplest of algorithms can achieve a gain in strength via multiple encryption; it simply serves to double or triple the keyspace. It does make things more difficult, but why do it when the security of the algorithm must be judged from a single encryption? How many times would one have to encrypt something with algorithm A so that algorithm A's keyspace is equivalent with algorithm B, which requires only one encryption? Regardless of what your intuitive definition of cryptography may be, there is no cryptographic algorithm which can be made absolutely, unequivocally one hundred percent unbreakable. Cryptography can never provide an eternal blockade to the original document, period. This applies to all crypto systems, past, present, and future. Cryptography by design is, and must be, a reversible "reaction" just like water can be turned to ice, and ice to water. Multiple encryption is seen by the crypto community as a weakness. If several algorithms are chained together, then the effective keyspace becomes larger, but would such a system still be practical? What of key management? Multiple encryption with the DEA is not recommended as the file size will double with every additional encryption. Sure, strength rises, but so does the time and storage requirement. In short, there is no advantage to multiple encryption with the DEA. If, however, the DEA is used in a situation where a number of workers contribute to a project, the supervisor may decide to implement a final supervisory post-DEA encipherment as a precautionary step. This way, access to the data requires two people: the supervisor, and some other person in charge of the DEA key. This is analogous to a bank vault having the combination split among two bank employees. This strategy can certainly be implemented; you may desire to use the DES as post-DEA encipherment as it is fast and uses a key no greater than seven (7) characters. Ciphertext will expand by zero percent with the DES in this situation. Chapter Six ═════════════════ 6.1 PREVIOUS VERSIONS OF THE DATA ENCRYPTION ALGORITHM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA was first released as a public evaluation on April 13, 1993. Several weeks thereafter, version 1.50 was released. These programs have similar internal workings but are all mutually exclusive as the result of Cipher Function and other minor and major enhancements. Version 1.00 and 1.50 did not expand the ciphertext as version 2.00 does now. They also did not incorporate the DEA v.2.00 Cipher Function. These previous versions produced their two one-time-pads externally to the DEA program. They do, however, incorporate the same mod-mult-random-feed algorithm as DEA v.2.00. The DEA Release v.2.00 is a transcribed work. DEA keys from these previous versions should be discarded and not used with the DEA v.2.00 even though the DEA key data structure has not physically been changed. 6.2 COVERT AND PRACTICAL CRYPTANALYTIC TECHNIQUES ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ All users of the DEA and other cryptographic software / hardware tools should be keenly aware that the term 'cryptanalysis' does not have to be interpreted scientifically; it can be applied effectively via pragmatic methodology. One tip to remember, before we examine the standard lot of covert and stealth techniques, is your wordprocessor. Wordprocessors typically produce back up files (.BAK), and or temporary timed as-you-work back up files which are deleted after you finish using the wordprocessor. To maintain a high level of information security, you are encouraged to delete the plaintext (.BAK) equivalent of files you intend to encode with the DEA with the MFD program. If you routinely encode documents with the DEA after you finish with your wordprocessor, always ask yourself "Do I have any plain versions of this file left in my system?" This is your cue so that you always check for the possibility of plaintext file equivalents. When you have a timed back up feature on your wordprocessor, the situation is a little more complicated. If you have a back up file, you can delete it via the MFD. However, timed back up data is usually directed into a file which is erased by the wordprocessor when you exit the program. At this moment in time, the timed back up file will probably contain a high percentage of the actual data in the real document. The timed back up file's data is not deleted from the disk; the entry in DOS's File Allocation Table is deleted, marking the disk space as available -- the actual data is still there! Since the MFD utility requires a file name to be supplied, the MFD cannot be used when a wordprocessor automatically deletes a temporary timed back up file. This is a problem which has no solution at the moment. It is important that you realize this, as ignorance of this fact may prove embarrassing. One possibility, however, is to load another file into the wordprocessor, make some deliberate changes to it, forcing the wordprocessor to create a new timed back up file, overwriting the older timed back up, then exit the wordprocessor without saving the changes -- they were deliberate. This is a workable solution, but take note that the old timed back up is only overwritten once by the new timed back up file of same or larger size, unlike the ten (10) times of the MFD. In such a hypothetical case, the data from the original timed back up file, could possibly be salvaged via very sophisticated data recovery hardware. There are many practical methods of 'cryptanalysis', and you must be aware that enciphering data is only a part of the overall information security procedure. It is absolutely essential to have trustworthy and reliable personnel and to follow strictly the procedures outlined by your firm's information security officer(s) for each corporate department where the principles of information security apply. Physical methods include burglary (the infamous Watergate Hotel scandal), rummaging through corporate or personal trash, stealing documents just before they are shredded etc. Covert methods include bribery, blackmail, and staff infiltration. Below, we look at two common stealth techniques. Traffic analysis is used to infer some useful information which may be pieced together later to build a case, for example. Here, it is of interest where the messages originate from, where they are transmitted to, the size of the messages, and the time of day the messages are sent. If the messages, for example, originate in Columbia, and they are sent to Miami, then we can infer at least something. Tempest analysis is a true stealth technique which can be implemented from within a well equipped van parked not far from the site. This involves the remote detection of electromagnetic signal emissions from your computer. Actually, they can see just about everything you type on your keyboard; this method is focused upon the electromagnetic signal emissions of the keyboard. With the design of the DEA, this method poses a very minimal threat to the DEA user, as the DEA key is only referenced via its ID number; the key is not physically typed out, and that's what this technique is geared up for. Still, they may see your OTP settings, and your file names. If this surveillance activity is suspected and you are creating new DEA keys, then you should, perhaps, use the GENKEY utility somewhere else, possibly in an environment where there are ten to twenty PC's close together; the electromagnetic signal emissions from all of these (provided they are being used), would be difficult to separate. Another interesting stealth technique involves the placement of a specifically designed computer virus which would intercept a key, encode it, and place the data somewhere on your hard disk where the designer would then extract it, decode it, and then have your very own key(s). As encryption algorithms become more sophisticated, the number of different covert strategies will also surely rise. There are many almost insignificant gaps and user oversights which can provide the practical cryptanalyst with just enough information to allow him to worm into your 'secure' system. The best advice is to become fully acquainted with the encryption system you use and then to analyze various scenarios known to pose potential security breaches. 6.3 DATA ENCRYPTION AND THE LAW ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Up to a few years ago, the field of cryptography was mostly limited to governments and special government departments such as national security, and the secret service. Of course, the average citizen, hackers, and trained experts have at one time or another undertaken to design and implement their own algorithms. This has certainly provided the NSA with a wealth of ideas, as cryptography is a science continually searching for diversity of technique. In 1991, the US proposed Senate Bill 266. This bill was mostly designed as anti-crime legislation. Within the text of the proposed legislation, there was a clause stating that all manufacturers of secure communications equipment be so designed as to allow the government to recover the plain text of whatever form the communication took when appropriately authorized by law. Although this bill was defeated, the government has introduced similar disturbing legislation which is designed to meet the same end objectives. Today, in 1993, the US government is proposing, just as it did in 1977 with the DES, a new cryptographic device called Clipper. Clipper is a hardware encryption device designed for telephonic equipment. It would seem that governments are uneasy, perhaps rightly so, about real information security tools, and the desire to standardize government encryption protocols is an indication of this fear. On the positive side, however, Clipper is an advance in telephone communications technology lending privacy and confidentiality to millions of users, a useful addition which has long been overdue. However, it is felt that the Clipper device will not survive in the free market if such exotic telephones are to cost upwards of $700 dollars. Indeed, it is far cheaper and more reliable to transmit private and confidential information (encrypted) via a standard modem-fascimilie card, which is now widely available. Despite the wide public mistrust of this new government spearheaded technology, the Clipper initiative seems bound for failure in terms of public acceptance. Perhaps most importantly, the Clipper initiative is a gauge of public and organizational opinion on the subject of information security in an 'ecosystem' of information dependence and mastery. As everyone's attention is turned to Clipper, we might pause and ask ourselves "What has the government planned in the non-voice computer encryption arena?" Are we headed for a police state? As you read the accompanying INTERNET articles, you will probably realize that Clipper, even if the tremendous odds are overcome, will not succeed in controlling crime of any nature. It must, therefore, be assumed that Clipper is a prelude of things to come - something bigger and far more widespread in terms of control over information. Here is a technical review of the unclassified data known about the Clipper chip taken from the INTERNET sci.crypt conference on April 21, 1993: //////////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ //////////////////////////////////////////////////////////////////////////// Article 15742 of sci.crypt: Path: lynx.unm.edu!umn.edu!news-feed-1.peachnet.edu!bogus.sura.net!darwin. sura.net!guvax.acc.georgetown.edu!denning From: denning@guvax.acc.georgetown.edu Newsgroups: sci.crypt Subject: REVISED TECHNICAL SUMMARY OF CLIPPER CHIP Message-ID: <1993Apr21.192615.3465@guvax.acc.georgetown.edu> Date: 21 Apr 93 19:26:15 -0400 Distribution: world Organization: Georgetown University Lines: 167 Here is a revised version of my summary which corrects some errors and provides some additional information and explanation. THE CLIPPER CHIP: A TECHNICAL SUMMARY Dorothy Denning Revised, April 21, 1993 INTRODUCTION On April 16, the President announced a new initiative that will bring together the Federal Government and industry in a voluntary program to provide secure communications while meeting the legitimate needs of law enforcement. At the heart of the plan is a new tamper-proof encryption chip called the "Clipper Chip" together with a split-key approach to escrowing keys. Two escrow agencies are used, and the key parts from both are needed to reconstruct a key. CHIP CONTENTS The Clipper Chip contains a classified single-key 64-bit block encryption algorithm called "Skipjack." The algorithm uses 80 bit keys (compared with 56 for the DES) and has 32 rounds of scrambling (compared with 16 for the DES). It supports all 4 DES modes of operation. The algorithm takes 32 clock ticks, and in Electronic Codebook (ECB) mode runs at 12 Mbits per second. Each chip includes the following components: the Skipjack encryption algorithm F, an 80-bit family key that is common to all chips N, a 30-bit serial number (this length is subject to change) U, an 80-bit secret key that unlocks all messages encrypted with the chip The chips are programmed by Mykotronx, Inc., which calls them the "MYK-78." The silicon is supplied by VLSI Technology Inc. They are implemented in 1 micron technology and will initially sell for about $30 each in quantities of 10,000 or more. The price should drop as the technology is shrunk to .8 micron. ENCRYPTING WITH THE CHIP To see how the chip is used, imagine that it is embedded in the AT&T telephone security device (as it will be). Suppose I call someone and we both have such a device. After pushing a button to start a secure conversation, my security device will negotiate an 80-bit session key K with the device at the other end. This key negotiation takes place without the Clipper Chip. In general, any method of key exchange can be used such as the Diffie-Hellman public-key distribution method. Once the session key K is established, the Clipper Chip is used to encrypt the conversation or message stream M (digitized voice). The telephone security device feeds K and M into the chip to produce two values: E[M; K], the encrypted message stream, and E[E[K; U] + N; F], a law enforcement field , which are transmitted over the telephone line. The law enforcement field thus contains the session key K encrypted under the unit key U concatenated with the serial number N, all encrypted under the family key F. The law enforcement field is decrypted by law enforcement after an authorized wiretap has been installed. The ciphertext E[M; K] is decrypted by the receiver's device using the session key: D[E[M; K]; K] = M . CHIP PROGRAMMING AND ESCROW All Clipper Chips are programmed inside a SCIF (Secure Compartmented Information Facility), which is essentially a vault. The SCIF contains a laptop computer and equipment to program the chips. About 300 chips are programmed during a single session. The SCIF is located at Mykotronx. At the beginning of a session, a trusted agent from each of the two key escrow agencies enters the vault. Agent 1 enters a secret, random 80-bit value S1 into the laptop and agent 2 enters a secret, random 80-bit value S2. These random values serve as seeds to generate unit keys for a sequence of serial numbers. Thus, the unit keys are a function of 160 secret, random bits, where each agent knows only 80. To generate the unit key for a serial number N, the 30-bit value N is first padded with a fixed 34-bit block to produce a 64-bit block N1. S1 and S2 are then used as keys to triple-encrypt N1, producing a 64-bit block R1: R1 = E[D[E[N1; S1]; S2]; S1] . Similarly, N is padded with two other 34-bit blocks to produce N2 and N3, and two additional 64-bit blocks R2 and R3 are computed: R2 = E[D[E[N2; S1]; S2]; S1] R3 = E[D[E[N3; S1]; S2]; S1] . R1, R2, and R3 are then concatenated together, giving 192 bits. The first 80 bits are assigned to U1 and the second 80 bits to U2. The rest are discarded. The unit key U is the XOR of U1 and U2. U1 and U2 are the key parts that are separately escrowed with the two escrow agencies. As a sequence of values for U1, U2, and U are generated, they are written onto three separate floppy disks. The first disk contains a file for each serial number that contains the corresponding key part U1. The second disk is similar but contains the U2 values. The third disk contains the unit keys U. Agent 1 takes the first disk and agent 2 takes the second disk. Thus each agent walks away knowing an 80-bit seed and the 80-bit key parts. However, the agent does not know the other 80 bits used to generate the keys or the other 80-bit key parts. The third disk is used to program the chips. After the chips are programmed, all information is discarded from the vault and the agents leave. The laptop may be destroyed for additional assurance that no information is left behind. The protocol may be changed slightly so that four people are in the room instead of two. The first two would provide the seeds S1 and S2, and the second two (the escrow agents) would take the disks back to the escrow agencies. The escrow agencies have as yet to be determined, but they will not be the NSA, CIA, FBI, or any other law enforcement agency. One or both may be independent from the government. LAW ENFORCEMENT USE When law enforcement has been authorized to tap an encrypted line, they will first take the warrant to the service provider in order to get access to the communications line. Let us assume that the tap is in place and that they have determined that the line is encrypted with the Clipper Chip. The law enforcement field is first decrypted with the family key F, giving E[K; U] + N. Documentation certifying that a tap has been authorized for the party associated with serial number N is then sent (e.g., via secure FAX) to each of the key escrow agents, who return (e.g., also via secure FAX) U1 and U2. U1 and U2 are XORed together to produce the unit key U, and E[K; U] is decrypted to get the session key K. Finally the message stream is decrypted. All this will be accomplished through a special black box decoder. CAPSTONE: THE NEXT GENERATION A successor to the Clipper Chip, called "Capstone" by the government and "MYK-80" by Mykotronx, has already been developed. It will include the Skipjack algorithm, the Digital Signature Standard (DSS), the Secure Hash Algorithm (SHA), a method of key exchange, a fast exponentiator, and a randomizer. A prototoype will be available for testing on April 22, and the chips are expected to be ready for delivery in June or July. ACKNOWLEDGMENT AND DISTRIBUTION NOTICE. This article is based on information provided by NSA, NIST, FBI, and Mykotronx. Permission to distribute this document is granted. //////////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ //////////////////////////////////////////////////////////////////////////// The social impact of the clipper chip warrants close attention and may even result in the outlawing of all other forms of data encryption, and give the US a North American monopoly over all corporate and private information. These fears are real and you are encouraged to think about it now. For example, private data encryption in Spain is illegal. There are also other countries on the globe which prohibit private sector encryption. Still, it is very interesting to observe the US's initiative and proposed implementation of this new technology. There are several main reasons why governments are uneasy about real data encryption tools: they expend considerable resources in the attempt to recover the original plain text, often failing. They desire to control subversives, terrorists, spies, drug lords, and plain criminals. Of course, this is laudable; we all want to be as safe and secure as possible. Anyone who offers real information security tools, would be just as guilty as those who perpetrate the crime. The only sure method of combatting destructive forces is the complete outlawing of all data encryption, or the standardization of encryption technology on as wide a scale as possible. The legal issues raised by information security and law enforcement are formidable. If laws are invoked to make all non-government approved encryption algorithms illegal, then nobody except the government itself will have true privacy. This scenario is a very real possibility in the near future! Where do we draw the line between security and control of crime? Can crime be effectively combatted by other means? How much of a hindrance does top-of-the-line information security pose to the pursuit of law enforcement and the weeding out of subversives and undesirables? Can rigorous control over electronic information really reduce crime and other negative social ills by 50 to 75 percent? By ten percent? By five percent? Has the outlawing of information encryption in Spain resulted in a better country to live in? Thus, if the government intends to implement some or all of the threatened possibilities hanging over information security like a dark and ominous cloud, it must provide conclusive proof to these and other questions. If such proof is not forthcoming, then we can all continue to enjoy our freedom and just privacy. Nellis du Maurier Information Security wishes to provide the best information security possible, but does not desire to obstruct the law. If the DEA v.2.00 does become involved in a criminal case, it is the responsibility of the accused to provide law enforcement authorities with the key data; Nellis du Maurier has no method whatsoever of determining the key; there are no shortcuts, trapdoors, analytic methods, nor duplicate keys in the DEA v.2.00 system; only brute-force attacks will succeed, and these will require more time than can be humanly tolerated. In the next few years, you will probably hear much more about information, privacy, and data encryption. Unlike the other major infrastructures we currently have such as bridges, highways, telephones, etc., the electronic information networks and the resultant electronic information infrastructure has only begun around 1986, it is only about seven (7) years in the making. As more and more information is routed and stored electronically, the issues of privacy, confidentiality, and of necessity, encryption will come to the fore. If you are concerned or just interested in cryptography, new trends, new products, the politics of data encryption, you may want to check into the INTERNET. One conference is mostly technically devoted, the other is mostly devoted to the political ramifications of this information technology on society presently, and in the near future. 6.4 THE DEA ADVANCED COMMERCIAL VERSION - DEA ACV v.2.00 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA Release v.2.00 operates with a key length of one hundred and eighty (180) bytes, or 1,440 bits. This is far more than the DES (56 bits), IDEA(tm) (128 bits), and all other private sector cryptographic tools currently available and in use. This probably also includes the new clipper hardware chip for telephonic equipment. Breaking the DEA entails the process of trying all 1,440 bit permutations applied to, say, the first 160 bytes of DEA ciphertext to determine if intelligible plain text resulted. This does not take into account the OTP setting which is also key information. The OTP value forces the brute-force attacker to try all (modestly) 10,000 OTP variations for each 1,440 bit key. Thus, breaking even the DEA v.2.00 is not at all likely via brute force means. It can be done in theory, and in practice given enough time, but by that time, the attacker will probably be in the ground and will have lost interest. The brute-force strategy is the only method of breaking the DEA, as the DEA can and will sever completely all relationships between plaintext and ciphertext. The question now is: "What can be done so that the DEA ciphertext will resist attack, even if the correct key and OTP data is applied?" If the DEA ciphertext could be purposely 'corrupted' by some means, then even if the correct key data were applied, original plain text information recovery would not succeed, period. The purposeful 'corruption' serves to place the DEA ciphertext into a 'security envelope'. Now, both the original plaintext is in a secure 'envelope' (DEA ciphertext), and the true identity of the ciphertext itself is protected. A simple idea would be to encipher the DEA ciphertext, resulting in the user having two keys, on for the DEA and another for the post DEA encipherment. However, if the attacker knew that the user was using DES as post DEA encipherment, then the attacker must go through all DES keys, all DEA keys, plus all DEA OTP settings. This is an extremely arduous task and would require thousands of Cray super computers. But, as unappetizing a task as it is, even this can, in theory, be reversed. This simple idea does not expand the DEA ciphertext itself, and succeeds in raising the work factor enormously. Whatever means are used to cloak the end result of any ciphertext, one fact holds true: the work factor is increased and the possibility of reversing the many 'envelopes' remains constant at greater than zero. If we make the effective keyspace larger, we make the brute-force strategy a more torturous affair, and we buy ourselves more private time. While the answer to the above question has not been decisevly settled, the best median seems to be the adoption of a two hundred (200) byte random user defined key. Thus, the DEA ACV v.2.00 will use the standard DEA key structure plus an additional 200 byte key to protect the DEA ciphertext itself. This will effectively raise the DEA keyspace to 2^2,304,000 or 256^36,000. Further, the ACV will define the usage of the Start Vector, a value between zero and nine. The Start Vector is defined in DEA v.2.00 as zero. It should be noted that only the first few Stop Addresses of the DEA ciphertext are susceptible to brute-force attack; the 200 byte user key is designed to cloak the true identity of these Stop Addresses. The user defined 200 byte key will physically reside within the DEA.KEY file, but the DEA ACV key file will not be compatible with DEA v.2.00. Registered users can select the length of the user defined key from 200 to 2000 bytes. This program's application of this key does not require much time at all; it is not a full file encryption, it is only designed to protect the first few x-number of DEA cipher bytes from vulnerabilities of a brute-force attack. Note that the application of the DEA ACV 2.00 key and OTP will not recover the plaintext; the user defined key must be used first, this is just what we want. The DEA ACV v.2.00 will become available in January 1994, pending demand. 6.5 DEA PROBLEM REPORTS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA Release v.2.00 was designed to be operated under the MS-DOS(tm) operating system by standard IBM(tm) and compatible hardware. Any problems reported with DOS 5, or 6 will receive prompt attention. The DEA may or may not operate as documented with other operating systems. In these situations, problems would most likely be associated with command line switches, and redirection pipes. If you have a troublesome problem, you are asked to complete the DEA PROBLEM REPORT. There is a file in the DEA package called PROBLEM.RPT for this purpose. Please specify your operating system, and the difficulties you encountered, along with the particulars of the situation. Please make a note of any line number indicated by the particular program. Nellis du Maurier will investigate all problem reports, but will not guarantee a successful resolution for all cases. Chapter Seven ═════════════════ 7.1 PRELUDE TO THE DEA SECURITY ANALYSIS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ During the development of the DEA, Nellis du Maurier evaluated many of the available shareware data encryption products offered by various merchants. Most provide adequate protection from moderate threats. Some used compression, most simply adopted the 16-year old DES 'standard', and some went their own way and implemented their own proprietary algorithms. One product stated that 'Level 2' encryption was based on the DES algorithm, but used only one (1) of the sixteen (16) rounds of encipherment. No mention was made as to just which DES mode is being used. Electronic codebook? Cipher block feedback? Cipher block chaining? One product, of respectable calibre, used no less than five (5) pseudorandom number generators, PRNG's. However, all except one program, used the standard secret password approach to data encipherment. That one exception was an implementation of the Israeli Mossad technique. Indeed, the many methods in the science of cryptography is 'limited only by the imagination'. One product, was a true implementation of the RSA system, but because of the RSA mathematics, it could not use long RSA keys. It would seem, then, that although cryptography as a science implicitly demands creativity, there has been very little creative progress judging from the available wares. The data security products offered by numerous merchants, and the technology embodied within them, is very old news to the National Security Agency (NSA), and other government agencies. The real problem with these products is that most are outdated, and are trivial programs. But, even a very simple cipher can deter an individual from making an attempt to read your private mail or documents. The available products, up to now, seem to have only envisioned moderate security; and this is fine for most private sector uses of cryptography. How can an individual judge the quality, security, and strength of an information security tool? If you have no experience with cryptography, then you cannot make such evaluations. How do you go about evaluating a product which employs technology never before heard of, like the DEA? The ciphertext of one algorithm looks just as random as the next. Not simple at all. There is no getting around the fact that you must have some experience, and an understanding of a number of cryptographic principles and techniques. An information security consultant can certainly help in evaluating a product, and giving you valuable feedback. However, there are several aspects which even an inexperienced person may use to determine the strength of an algorithm as follows: 1. does the algorithm break all statistical, structural, and linguistic correlations between the plaintext and ciphertext? 2. does an analysis of the ciphertext allow for the recovery of the key, or plaintext? 3. can the traditional plaintext-ciphertext analysis be used to advantage? 4. can the ciphertext be in any way used to attack the algorithm's weak spots? 5. How many different methods are available for attacking either the ciphertext, or the key? (the fewer, the better) 6. how large is the keyspace? Even if the algorithm holds up against the above four (4), if there are only 10,000 keys, even a PC XT can go through all of them in less than 24 hours. In general, good cryptographic algorithms are designed so that ciphertext cannot be used against the algorithm itself. If this one paramount principle is strictly adhered to, the attacker is given no other choice, and he must then employ a brute-force key attack. A brute-force key, or keys attack will always succeed, in both theory and practice. This fact hangs like an anchor about the neck of the science of cryptography. If it can be "done", it can also be "undone". So then, even if the attacker must undertake a brute-force methodology, what provides the "security" of the system? The four factors listed above are typical shortcut strategies which are used in the science of cryptanalysis. Most cryptographic algorithms leave faint tell-tale signs of their inner algorithmic procedures within the ciphertext, and these minute patterns carry-over into the ciphertext where the science of cryptanalysis fully exploits their existence. Now, if the ciphertext itself cannot be exploited, then the attacker must go through a key attack. In modern cryptosystems, it is only the key which provides the security. All modern systems use a fairly long key. The best example here, is the true one-time-pad, where the key is as long as the message itself. It is the trial-and-error process of trying all keys which is so painstaking and time consuming. Attacking even the DES by 'hand' would be impossible. But, with modern computers, brute-forcing an algorithm is much easier, and the time required for this procedure depends solely upon the speed of the computer. Consider this: there are 256^7 keys in the DES algorithm, suppose that a supercomputer could calculate and verify all 256^7 keys in one (1) hour. This now means that your message / document can be deciphered in only one hour. Where is the security now? Security and time are synonymous terms in cryptography. Thus, we can say without reservation, that as computer speed increases, the security provided by all cryptographic algorithms will decrease by the same factor. It is the time required to try one key which actually defines the security of the algorithm, in the measuring unit of time, provided there are no analytic shortcuts. The large number of keys in a system is what provides the 'timed' security. 7.2 THE DEA v.2.00 SECURITY ANALYSIS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ While is possible to create many different cryptographic algorithms of various strengths with different design criteria, the basic fact of all cryptosystems is that because they are reversible 'reactions', they are therefore all open to attack, as it is precisely this fact of reversibility that introduces the inherent weakness into all systems. The attack upon any algorithm must be based upon a thorough understanding of the algorithm in question. This is the reason why military cipher algorithms are kept secret. If you can not make reasonable working assumptions about the algorithm in question, then you are effectively shut out from building any empirical data. The attacker must, in this case, use all his cryptographic knowledge to slowly gather working assumptions about the unknown cipher used. The DEA uses two internal one-time-pads which contain only the digits zero through nine. These digits can be thought of as a permutation of x-number of digits, the actual total permutations possible in these one-time-pads is defined thus: P = 10^otp_size where otp size is the size (in digits) of the one-time-pad Thus, a one-time-pad size of 6,500 digits gives: P = 10^6,500 The DEA's maximum 'permutation space' is therefore: 10^20,000, given the maximum OTP setting. If the one-time-pad size is say, 3 digits long, we then have 10^3 possible permutations of 3 digits. We can represent these possible permutations as ranging from 000 to 999. If our OTP was set to 6 digits only, then we have 10^6 possible permutations ranging from 000000 through to 999999. We may think of 000000 as the 'first' permutation of 6 digits, and 999999 as the 'last', or 'highest' permutation of 6 digits. This is just like the combination locks on some briefcases. SELECT DIGIT FRAME SUMMATIONS AND THE SIZE OF THE STOP ADDRESS -------------------------------------------------------------- The DEA is able to satisfy the DEA Cipher Function in the majority of cases. 'Cases' here is used to signify the input data set consisting of: 8-bit plaintext byte one-time-pad permutation 'P' select digit stop address byte value We must understand that there are two (2) random processes at work in the DEA. The first is the random one-time-pad, the second is the random multi-XORing of the DEA Cipher Function. Different one-time-pads will have a different select digit "frame summation". The frame summation will explain why a different OTP will produce a different 16-bit address given the same input data set. To examine why the majority of addresses are less than 5,000, we need to examine the frame summation and the XORing together. A different frame summation will lead to a different XOR sequence. As observed, the XOR sequence is relatively short for the majority of data input sets. What does this short XOR sequence indicate about the XORing and the frame summation? Obviously, the random numbers extracted from the frame led to an XOR sequence in which the plaintext byte was transformed into the stop address byte value in short order. Most of the frame summations are values less than 100. The reason why the majority of addresses are less than 5,000 is because the frame summations are significantly different from each other so that the XORing "moves" the byte value along. In high DEA addresses, the XORing does not "move" significantly in any direction for a while, thus XORing 50 with 17, then 13, then 27, then 22... does not "move" the byte value very much, as with frame summations of greater distance variety. Therefore the reason for the DEA Stop Address size is the direct result of the 'distance' between the successive select digit 'frame summations'. The larger these distances, the more the XORing 'moves' the byte in either direction faster. In general, the larger distances produce smaller Stop Addresses, while smaller distances cause the Stop Addresses to enlarge. So, yes, the one-time-pad is responsible for this phenomenon. Can any statistical inferences be drawn from the DEA Stop Address sizes? While inferences and hypothesis can certainly be drawn, they will not aid in the process of analytic attacks. Larger OTP values will cause the DEA Cipher Function to be satisfied in the majority of cases. Such statistical methods give a clue as to the nature of the SD frame summation values, but lead to a dead end when attempting to link Stop Address size to either plaintext, or key information. HOW DOES THE ATTACKER PROCEED FROM STOP ADDRESS TO PLAINTEXT? ------------------------------------------------------------- There is no direct link between a DEA Stop Address and the original 8-bit plaintext value of any kind. The 8-bit plaintext byte value does, however, act as a 'control variable'. In other words, XORing begins from this value, and ends with the SABV value. The 8-bit input byte represents only 25% of the total DEA Cipher Function's data input set. There is no method of reversing this if the Cipher Function's data input set is not conclusively known beforehand. If such an attempt is made without certainty, it will result in the DEA Multiple Solution problem wherein many different data input sets will result in the same Stop Address, and there is no method available to prove the correctness of a DEA Cipher Function data input set by this trial-and-error approach. SO HOW COULD THE CRYPTANALYST ASCERTAIN THE CORRECT VALUES FOR THE SELECT DIGIT AND STOP ADDRESS BYTE VALUE? ------------------------------------------------------------------------- These control variables only control the DEA Cipher Function's multiple XORing, and although they are responsible for the resulting Stop Address, there is no way of going backward. They are not combined with the Stop Address in any manner. WHAT CAN BE SAID ABOUT TRADITIONAL PLAINTEXT-CIPHERTEXT ATTACK STRATEGIES? -------------------------------------------------------------------------- As illustrated, the DEA cryptogram bears no structural, statistical, or language specific correlations with the plaintext; it is completely devoid of all plaintext correlations. The DEA has effectively severed any and all traditional plaintext-ciphertext relationships. The availability of partial plaintext and DEA ciphertext will compromise neither the remaining ciphertext, nor the DEA key. IS THERE THE POSSIBILITY OF THE CRYPTANALYST DETERMINING ANY CORRECT INFORMATION WITH REGARD TO THE CRITICAL UNKNOWN CONTROLLING VARIABLES OTP, SD, SABV, AND PLAINTEXT? --------------------------------------------------------------------- The answer here is no. The basic reason for this is the DEA's multiple solution problem. If there was but one solution for any of the data input set variables, it would then be possible to ascertain for certain the actual values, but with multiple solutions, none of the control variables may be determined with accuracy and precision. All control variables, with the possible exception of repetitive plaintext, oscillates on a byte-to-byte basis. EXPLAIN WHY THE DEA IS COMPLETELY DEVOID OF ALL PLAINTEXT - CIPHERTEXT RELATIONSHIPS. ---------------------------------------------------------------------- The 'ciphertext' of the DEA is an EVENT, not a series of eight (8) scrambled bits. The DEA records WHERE in the one-time-pad the DEA Cipher Function's data input set was satisfied. The ciphertext is actually an address, but may be considered as a 'timed event'. Since the DEA incorporates two (2) random processes, the DEA Cipher Function is able to completely sever all plaintext to ciphertext relations. BRUTE-FORCE ATTACKS BASED ON KEY PERMUTATIONS --------------------------------------------- The only avenue open to a potential attacker of DEA enciphered data is via brute-force, that is, trying all possible 1,440 key bit permutations. There is no shortcut method available in the DEA system. Brute-force attacks will succeed with the DEA, just as surely with all other systems. Since the DEA also treats the OTP value as key information, the brute-force attack is not as clear-cut as it might be with other systems; the OTP value increases the work factor substantially. EXPLAIN 'RUNNING INTERNAL KEYS' ------------------------------- The DEA creates a key for every input byte the DEA must process. Most importantly, the DEA creates a one-time-pad for every plain byte. The original user key provides the control over the Cascade Synchronization produced by the system when it creates new one-time-pads. The Cascade Synchronization is determined by the user key, and the plaintext data. The plaintext data provides the control mechanism for the creation of new one-time-pads as it affects the original fractions defined by the user key data. Thus, a running DEA key is one which has its fractions modified by DEA frame summation values. The SD, and SABV values are not affected; they remain constant throughout the DEA process. The term 'running internal key' is to be understood as a concept, not an exact entity. While a running DEA key also contains 1,440 bits of key data, such a hypothetical key cannot be applied to DEA ciphertext as this key has no way of going 'forward', that is, it cannot maintain the original Cascade Synchronization. The one-time-pad which serves as a random feed, provides further security, as an OTP of length (x) is applied to each and every running key. Therefore, the DEA running key, is protected by a 10^10,000 byte permutation, if the user selected an OTP of 10,000 digits. ENTROPY AND THE DEA V.2.00 -------------------------- In the cryptographic past, the principle of entropy, or the measure of physical disorder of a system, was a principle of integral importance in the science of cryptography. This principle is usually applied to the ciphertext output of an algorithm for analytic reasons. We know that all cipher algorithms alter the original intelligible patterns of entropy into a new 'language' of differing entropy designed to be unintelligible. We also know that the algorithm (a systematic procedure for something) will leave some faint tell-tail residues in its output. When the entropy of the ciphertext is uniformly distributed, then it is much more difficult for the cryptanalyst to obtain a statistical 'grip' on the entropic environment he needs to analyze. If we were to subject this paragraph to various language analysis, we could compile a number of useful statistics. However, where the data bytes are uniformly distributed over the entire alphabetic spectrum (our English alphabet, ASCII, EBCDIC, etc.), we can make very few statistical statements, except that all byte values are equally likely to appear with relatively equal frequency. The principle of entropy can be applied to all cipher algorithms which employ substitution, transposition, or both. Entropy cannot be applied to systems which are based upon mathematical operations such as the RSA, or the Knapsack. That is to say, the principle of entropy cannot be applied blindly and universally to all cryptographic algorithms. The principle of entropy is fundamental to all of cryptography, as each algorithm manipulates the original natural language entropy into a new entropic language. But, it is interesting to note that not all algorithms produce the new entropy via the same methods. Some algorithms rely heavily upon some random function, or set of random functions as the source and supply of their entropy. There are also algorithms which do not rely on an internal supply of entropy with which to combine the plaintext. Instead, these algorithms directly combine the plaintext with some type of reversible, or invertable mathematical function, such as in the RSA design. Despite the two divergent methods which can be employed, the desired net effect of transforming the original entropy into a new unintelligible entropy is achieved in both systems. In effect then, encryption is an algorithm dependent translation process. The principle of entropy in the DEA system is provided by the enormous permutation space available from the one-time-pads. An OTP setting of 7,000 will provide 10^7,000 total 7,000 digit one-time-pads from which to draw select digit frame summation values. This is the source of the entropy in the DEA. While the DEA does combine the SD frame summation values with the plaintext byte a random number of times, the final output is not a scrambled 8-bit byte, but rather, it is an address indicating where in the one-time-pad the DEA Cipher Function's data input set was satisfied. The DEA ciphertext does not display uniform probability space. With an OTP of 20,000 digits, most DEA Stop Addresses will be less than 9,000. Is this a weakness? What might it indicate about the C.F. data input set? The size issue of the Stop Address has been addressed previously. It does not matter whether the plaintext byte is in the low ASCII end or the high end; large Stop Addresses may result from any ASCII byte value or any C.F. data input set. The non-uniform Stop Address distribution is actually a strength, rather than a weakness. It is a strength because of the DEA's Multiple Solution Problem wherein completely different ASCII byte values can map to the same or relatively same Stop Address. It is interesting to note that this non-uniformity can not be exploited to advantage. With other traditional systems this fact could and would be immediately exploited. The ASCII 8-bit input byte and the resultant Stop Address display no direct correspondence or relationships. We can never say that this byte value maps to this Stop Address. The mapping is random and cannot be computed in advance. If all C.F. data input set control variables are held constant, but not the one-time-pad, then there is still just as much Stop Address variety. If the one-time-pad along with the other C.F. data input control variables were to be all held constant, then the same Stop Address would result every time. Therefore, it is the one-time-pad which is directly responsible for the Stop Addresses. It is interesting to observe that while there is great permutation entropy in the one-time-pads from byte to byte, there is a lesser degree of entropy in the resulting Stop Address distribution. However as we have noted, this non-uniform distribution cannot be cryptanalytically exploited, just as entropy analysis cannot be applied to pure RSA ciphertext. If the ciphertext of a particular algorithm is not a product of substitution, transposition, or both, or some other invertable function, then analysis based upon entropy will fail to yield any conclusive results. The application of entropy to the RSA, for example, is cryptanalytically ridiculous. It is also futile to apply this principle profitably to the DEA Stop Addresses in the hope of getting a statistical 'hook' into the system. WHAT CAN BE SAID ABOUT THE STOP ADDRESS SIZE AND THE NUMBER OF XOR'S? --------------------------------------------------------------------- Suppose we have the Stop Address N and we wish to know how many times the XOR operation was used, that is, starting with the plaintext byte P and ending with the SABV, how many XOR's were performed? It is known that given a Stop Address, the number of XOR's lies in the range (N - 90%) to (N - 93.9%), which is roughly 6.1% to 10% of the Stop Address. The uncertainty variance factor is 3.90% of the Stop Address. Now, let us examine if we can make any reasonable working assumptions with regard to this fact. Suppose we have a Stop Address of 4904 and the number of XOR's was known to be 404 (actual case). We also know that the plaintext byte P was transformed into the SABV via the agency of 404 XOR steps, that is, 404 random numbers were scooped off the one-time-pad and XOR'ed with P to result in the SABV value and the resultant Stop Address is 4904 at this point. Can this information be applied to the attack of any DEA Stop Address? The short answer here is that while this method of attacking the DEA would seem to hold the greatest promise, it leads to complete frustration. It is not possible to prove the values P and SABV beyond doubt given the existence of Multiple Solutions. The only method of proving P and SABV is to to also have knowledge of the actual one-time-pad for this data input set. The one-time-pad cannot be reconstructed via knowledge of the Stop Address, or the assumptions we have made here. All the DEA's C.F. input data must be known beforehand to prove with absolute certainty that this is how P was transformed into the SABV, and thus, the Stop Address; the DEA is unique in that it leaves absolutely no room for hypotheses and conjectures - either the Cipher Function's data input set is known, or it is not, there is no manner in which this fact can be circumvented. As a side note, larger OTP settings increase security via increasing the uncertainty as to the OTP's exact construction. WHAT IS THE RELATIONSHIP BETWEEN SUCCESSIVE ONE-TIME-PADS? ---------------------------------------------------------- As with pseudorandom number generators and decimal periods from, for example, 171 / 22307, there is a relationship between successive random numbers, and also between successive digits of the decimal expansion. We can define the explicit relationships via the agency of a formula. The DEA's one-time-pads correspond to a function of many (thousands) of independent sub-functions. With simple PRNG's, knowledge of only one random number will allow all others of the sequence to be produced. This is not the case with the DEA's one-time-pads. While there is some degree of interdependence, the random feed to the mod-mult algorithm effectively prohibits the drawing of such conclusions; it is the n-digit long random feed, together with other variables which control the relationship(s) between successive one-time-pads. No statement is being made here to the effect that there is no relationship(s), rather, the relationships are controlled by other factors which are possessed of extremely large degrees of variability. The actual relationships are controlled by all aspects of the DEA Cipher Function data input set, including the plaintext. EXPLAIN WHY THE DEA ONE-TIME-PAD IS UNIQUE ------------------------------------------ The DEA's one-time-pad is just like the decimal expansion of a rational fraction. However, unlike a plain decimal expansion where ALL quotients correspond to a single modulus, the DEA's decimal expansion is an unnatural one in that it employs as many moduli as are necessary to produce the required decimal length. Such an unnatural decimal period will never correspond exactly with a decimal period derived from a 'natural' or single modulus. Many statistical properties of natural decimal periods especially the reflexive cycle property is completely eliminated when multiple moduli are employed in this fashion. While there are other statistical considerations, their ranges and paramaters are fairly consistent, as they should be. It is from this decimal period that the Select Digit Frame Summation (SDFS) values are derived, which is the DEA's source of entropy. WHAT TYPE OF CIPHER IS THE DEA? ------------------------------- The DEA is a conventional cryptosystem, as opposed to a public key system. It is a stream cipher operating upon one (1) eight bit byte at a time. The DEA is not a block cipher such as Lucifer, and its butchered cousin, the DES. Further, the DEA does not combine the key with the plaintext, as is almost universally the case. Also, each eight bit byte is processed as a single and separate entity; it bears no relation to a past or next byte. The DEA is a symmetrical system, meaning the same key applies to both encoding and decoding. CONCLUSIONS OF THE SECURITY ANALYSIS ------------------------------------ We conclude that the DEA v.2.00 is computationally secure but not unconditionally secure. We further conclude the DEA ciphertext is not vulnerable to attack by traditional cryptanalytic techniques, or by methods specifically tailored to the DEA itself. We conclude the DEA may be broken only by brute-force key trials. Since the DEA's keyspace is 256^180, or 2^1440, it will require far more time for a brute-force attack to succeed with the DEA as contrasted to the best public algorithm(s) including the 80-bit Clipper voice encryption chip. It is surmised that the DEA with just a 180 byte key is less secure than the RSA algorithm with a 500-digit prime key number. This results from the fact that one key is 180 bytes while the other is 500 bytes; this difference should be obvious. The DEA ACV addresses this issue with the 200 byte random user-defined key. Also to be considered in this comparison, is the different methods employed for brute-forcing each algorithm, if indeed the RSA has been used in its 'native' non-hybrid mode. In general, all other things being equal, the longer the key, the more time consuming and laborious the brute-force attack will be. However, as the RSA is employed mostly as a hybrid system wherein the bulk of the actual document / message is processed by a more time-respecting algorithm such as DES, IDEA(tm), or some other, it can be said that the DEA is superior to the RSA in THESE HYBRID CASES ONLY. This assessment is based on the known key length of the RSA-secondary algorithm. POINTS TO REMEMBER ------------------ Contrary to what others may believe to be the case, cryptography can NEVER provide absolute unequivocal guarantees of security if we understand that the term is used in a reversible sense. The more 'secure' the system, the more it will border on irreversability, and as we know and understand, encryption must be reversible to be useful, as it is information we wish to MAINTAIN but NOT SHARE for a period of time. For example, the Beale Cipher is a unique cipher, but with the loss of the key document, it becomes non-reversible, and thus, it loses its usefulness. The task of combining the pragmatic element with the element of security is not at all easy. And, it is indeed these two functionally opposed needs which control the science of cryptography. Given these unmovable theoretic facts, it is comforting to know that cryptography does work, is used, and will be used and relied upon even more in the near future. Apart from physical methods, cryptography is the only solution to the information problem MAINTAIN but NOT SHARE. Chapter Eight ═════════════════ 8.1 REGISTRATION AND ORDER FORM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The registration fee to continue using the DEA beyond the 30 day trial evaluation period is twenty (20) US dollars, or thirty (30) dollars Canadian funds. Overseas orders are accepted in the form of international money order. Please note that there are no fees beyond the registration fee; it is considered "payment in full". Please print the file REGISTER.USR, fill it out as indicated along with your check or money order. Registration entitles you to program updates at significant savings. You will also be advised of DEA security analysis issues. The DEA ACV 2.00 is also available to you, once you become a registered user. Negotiated corporate site licenses are available. Please write the firm at the address below: Nellis du Maurier Information Security 33 Isabella St., Ste. 1005 Toronto, Ontario M4Y 2P7 Canada 8.2 DEA USER FEEDBACK ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The software you are using is a genuine Nellis du Maurier product. Nellis du Maurier is pleased to hear from its end users regarding their information security needs and these products. If you require additional features, and / or products, please contact the above in writing. Pleae note that special features are considered 'custom programming projects', and prices will vary according to the nature of the requested features. Updates for the Shareware version are scheduled for regular intervals and will incorporate the most requested features. Thus, user feedback is strongly encouraged. 8.3 THE DEA v.2.00 OPERATING SPECIFICATIONS ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ Although a seasoned professional will be able to make sense of the internal operating characteristics of the DEA v.2.00 algorithm, these specifications and the entire design of the algorithm are the property of Nellis du Maurier Information Security. The company desires to encourage discussion, inspection, and analysis of the DEA design, but at the same time desires to maintain control over its commercial rights to the algorithm. At the time of this electronic printing, the DEA is protected by the copyright laws of Canada. It is also protected by Canadian intellectual property laws. A patent application for the DEA is scheduled for early 1994. While discussing the issue of algorithm availability and commercial protection, it is stated here that the DEA.EXE file contains an encoded author verification signature proving authorship in cases of dispute or theft. The algorithm design will be specified in a document called DEA2TECH.DOC. It will be distributed to the INTERNET on or before December 14, 1993. It should answer most questions that will arise. Nellis du Maurier Information Security at its sole discretion, may, in a very few limited cases, supply the source code for the DEA only to qualified crypto professionals who need to be able to modify the source code at various points to allow selected DEA statistics to be gathered for inspection and analytic purposes. Chapter Nine ═════════════════ 9.1 THE DEA v.2.00 FILE SIZE DOUBLING PROBLEM ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ The DEA v.2.00 will double the size of the input file. This is an annoyance which both Nellis du Maurier and its users can live without. This problem emerged from the design of the new Cipher Function specifications. The issue was addressed, but no satisfactory method was found. Nellis du Maurier actively seeks user input regarding this problem. If you think you have found a reliable and efficient method to eliminate this problem, please send your ideas along with 'C' language source code example to the publisher. If your implementation is selected, it will be incorporated into the DEA, and the new version will be available to all. You will also be notified by mail of this decision. The problem is stated as follows: Design an algorithm which can convert a numerical value larger than 256 ('C' int data type) into a value less than or equal to 256. Specifically, an algorithm which can convert a 16-bit value into an 8-bit value, WITHOUT LOSS OF PRECISION of the 16-bit value. Thus, a DEA Stop Address such as 14,851 (16 bits) must be converted to an 8 bit data entity to prevent DEA ciphertext from expanding. Of course, the 8-bit value must allow the recovery of the actual DEA Stop Address of 14,851 EXACTLY, to allow the DEA to recover the enciphered message. A possible working idea might be a square root function in which the mantissa is discarded, but recovered via some algorithmic technique. Additional Information ══════════════════════ Nellis du Maurier Information Security is a registered company operating in the province of Ontario. It designs, markets, and sells computer information security products using the DEA technology. The company is registered at: Companies Branch Ministry of Consumer and Commercial Relations 375 University Avenue, Second Floor Toronto, Ontario M7A 2H6 Canada APPENDIX ════════ TIMING FUNCTION ERROR MESSAGES WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED? DEA COMMERCIAL VERSION CLEARING THE INTERNAL KEY DATA STRUCTURE A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE ANOTHER METHOD OF THE CREATING THE DEA KEY PROGRAM EXIT CODES - DEA.EXE only - TIMING FUNCTION --------------- The process time recording function used in the DEA does not provide midnight roll-over. For example, if you begin enciphering at system time 11:57pm, and the DEA process requires 5 minutes, the displayed time will not be correct; it may even show a value in the billion range. This is not really an error, it is a limitation of the library function itself which does not have this capability. This curio should not display itself too often. The process timing function does not provide EXACT timing; it provides an approximation. This strategy was chosen so as to avoid the inline floating point math emulation instructions which would have made the DEA.EXE file larger by about 25,000 bytes, and somewhat slower. The times shown on the screen following a DEA process, are approximations; they are shown in seconds (quite precise), minutes (fairly accurate), and hours (this should show zero most of the time, unless it actually takes that long) ERROR MESSAGES -------------- All programs in this package will generate error and / or usage messages if invalid data is supplied. Error return codes are listed below in the section PROGRAM EXIT CODES. WHY WAS THE GENKEY PROCEDURE NOT AUTOMATED? ------------------------------------------- Perhaps the most awkward and labour intensive aspect of the DEA package lies in the GENKEY utility. Once a DEA key has been established, using the DEA is a very simple matter indeed. It was suggested that a random number generator function could be employed to quicken and automate the key generation process. Despite the intuitive flexibility so obtained, it can be shown to drastically reduce the security of the DEA. Here is why: If a random number function is used to generate all aspects of the DEA key data, then the random number function must be INITIALIZED FIRST, otherwise we run the risk of having DEA users across the entire country using the SAME KEY! Suppose that the random number generator can be initialized, now the problem is that there are a limited number of ways in which the PRNG CAN BE INITIALIZED, for most such PRNG's, there are only 32,767 initializer 'seeds' AVAILABLE. Even if there were 4 billion (256^4) different ways to initialize the PRNG, 256^4 is no comparison to the DEA's keyspace of 256^180. The problem with automated key generation via a pseudo random number generators is that there are far fewer seeds to initialize them as there are keys in the DEA design. Consider, for a moment, that we are automatically generating a DEA key via this method, the user supplies a PRNG seed value, and then GENKEY produces a key. Since there are only 32,767 seed values for the PRNG, GENKEY can only produce 32,767 distinct keys! Now, an attacker's task of finding the correct DEA key has been reduced from 2^1,440 to 2^15. Of course, several PRNG's could be used for the prime divisors, numerators, imaginary fractions, select digits, and SABV's. However, this brings the attacker much closer to realistically breaking the DEA. Several PRNG's for GENKEY still make the attacker's task a relatively easy one, as the work factor is reduced from 2^1,440 to 2^60. Thus, in essence, a DEA key derived via pseudo random means makes the DEA just a little more difficult to break by brute-force than the DES, which as we know, can be brute-forced in 24 hours, or less in this day and age. Thus, although GENKEY is labour intensive, this crude, but purely random number selection method must be used to guarantee the integrity of the extremely large key space of the DEA; any PRNG automation of GENKEY reduces the keyspace to an almost insignificant magnitude. Generating the key manually is the only way to guarantee the randomness of the 1,440 bit key. In a manner of speaking, GENKEY represents the price to be paid for using the DEA. DEA COMMERCIAL VERSION ---------------------- Although this release of the DEA is far superior to all other currently available commercial and shareware information security products, more security is unequivocally better in cryptography. Given the constant speed increases of computers, the DEA can stay far ahead of any likely brute-force attacks via the agency of: 1. greater number of file blocks from the present ten (10) to say, 20 + 2. a user defined 200 byte (1,600 bit) random supplemental key 3. post DEA encryption via any available encryption algorithm Any one, or all of the above will help to maintain privacy longer in the face of ever faster computers. The DEA Advanced Commercial Version (DEA ACV 2.00) will address the issue of yet higher security via an expanded keyspace using a user defined 200 byte random key. This key shall be incorporated into the existing DEA key data structure. However, key incompatibilities between the standard DEA and the DEA ACV will arise. If you are a registered user of both programs, Nellis du Maurier will supply a conversion utility to ensure key compatibility across both versions. Availability of the ACV will be December 1993 or January 1994. Effective keyspace of the DEA ACV is: 2^2,304,000 or 256^36,000 Please note that the DEA ACV 2.00 will not be marketed via the Shareware distribution method. It will only be available to registered users of the DEA Release v.2.00. CLEARING THE INTERNAL KEY DATA STRUCTURE ---------------------------------------- Please note that the key data stored in the DEA key data structure during DEA processing is cleared to zero at the time of normal program exit. This assures you that no sensitive key data remains active in computer memory which could be found by a memory scanning utility. Note that all programs which use the DEA key data structure (DEA, GENKEY, & KEYVIEW) clear this data structure to zero before exit as well. A HELPFUL HINT FOR FREQUENT COMMAND LINE USAGE ---------------------------------------------- If you routinely use the DEA to encrypt and decrypt files, you may get tired with having to type the command line every time you perform a DEA operation. Command line usage can be made much more simple by using the following tip which relies on batch files. This is only useful if you do not change key ID values and OTP values frequently. Create a batch file with just the following contents: DEA /E /K4 /OTP4713 %1 %2 you can give this batch file the name "DEA-E.BAT" to signify encryption via the DEA. Create another batch file with just the following contents: DEA /D /K4 /OTP4713 %1 %2 give this batch file the name DEA-D.BAT for example, to signify decryption via the DEA. Now, whenever you wish to use the DEA, you can simply specify either: DEA-E file_in or DEA-E file_in file_out or DEA-D file_in Some Observations: 1. this is for MS-DOS usage 2. no flexibility in choosing OTP values 3. no flexibility in choosing key ID values 4. simple and short 'new' format 5. DOS redirection pipes will NOT work correctly When you want to change your key ID values and / or OTP settings, you should remember to edit your DEA-E and DEA-D batch files also. ANOTHER METHOD OF CREATING THE DEA KEY -------------------------------------- Here is a method which can be used to generate a DEA key. Although the data thus generated must be typed into the GENKEY program, the user is relieved from most of the task of thinking up the numbers. Remember that the technique described here cannot be used to generate a DEA key for immediate use by the DEA; it must still be submitted to GENKEY first. Here then, is the method: 1. run the KeyView utility, but instead of the normal file "DEA.KEY", specify another file type. It could be a .GIF, .PCX, .ZIP, .DEA, .EXE, .COM, .TXT, .DBF, or ANY OTHER FILE. KeyView will determine the number of keys available by dividing the said file type by 240. Remember that these are fictional DEA keys, but we just want to get some random numbers fast. 2. select a key from the available ones listed by KeyView 3. make a copy of KeyView's output file DEA_KEY.ASC, preferable on paper, or in a multi-windowed text editor. We must now change some values to acceptable ranges before submitting the key to GENKEY. In particular, we must make certain that the prime divisors are within proper ranges, and that other DEA key data is of proper data size. SABV: 0-255, SD: 0-9. For the prime divisors, you must make certain that ODD INTEGERS are entered, further, the PD's should not be enormous; see the Chapter 3.10 VALID DEA KEYS for further information. If you are still unsure as to the changes you must make to a DEA key from KeyView via this method, it is suggested that you examine the real DEA key with KeyView, and then create another DEA 'key' via this technique. PROGRAM EXIT CODES - DEA.EXE only - ------------------ Code Meaning ---- ------- 0 normal program start and exit 1 cannot open DEA.KEY file, even after the user is queried 2 selected one-time-pad is out of range 3 same as (2) above, different line number 4 unknown cipher mode 5 same as (2) above, different line number 6 cannot open input file -possibly the file does not exist, is misspelled, or is READONLY 7 cannot write output file -possibly not enough space, invalid path (embedded DEA path) 8 cannot open DEA.LOG file 9 same as (4) above, different line number 10 non-integral key file size - DEA.KEY file modulo 240 = 0 11 invalid key ID reference number ACKNOWLEDGMENTS ═══════════════ Nellis du Maurier Information Security wishes to extend a note of thanks to the many individuals who spread quickly and widely the DEA v.2.00. Sincere thanks also goes out to Mr. Philip Latimer, and Mr. Sander Schimmelpenninck who were both very much responsible for the DEA's maturity into a sophisticated, powerful, and useful software tool. Thanks also to the very many unnamed individuals who took the time to both download and later re-post this archive to their local bulletin boards. Thanks to all of you, you now have a software tool to fully protect your god-given right to information privacy. A tool which is head and heels above all others. A genuine Nellis du Maurier product you can use with justifiable assurance and confidence. ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀